From syslog-bounces@lists.ietf.org Tue May 01 01:10:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hikd5-000075-40; Tue, 01 May 2007 01:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hikd3-0008W4-FT for syslog@lists.ietf.org; Tue, 01 May 2007 01:10:21 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hikd2-0001II-8M for syslog@lists.ietf.org; Tue, 01 May 2007 01:10:21 -0400 Received: by wr-out-0506.google.com with SMTP id 76so1812047wra for ; Mon, 30 Apr 2007 22:10:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=pHwnjOsJ26pI0+i0DUId8sa55+VX0QNfM6a7aKBKsMxb5FMMwVcy1hNddlPgApbmKxTTQbytsLtHfpruDdcKpYLq2/alNU++p+t2FbDpEHguV6DksVZbQFaDjlpTBIWR6CKFXDyRpq4dvexRAtXA/ZWWCZ3WMFZFzkhMmH9KdlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=uhbs/7Fwf2OjNhG/j82bq5V3j5hfD3YHTdqZPPR4/HB3O3NN+nrQSk8UsUV4c9gntpM3rnf/nr54ZbAwrDff/lOgVk/oaIwc1c711lG3D9v2mXVmMfKV3wOHWZyyuZrf6RLrBYuO36Go6e32NqTcLchp+ke3ogWXPG2F9Iyxvl8= Received: by 10.114.158.1 with SMTP id g1mr2272466wae.1177996219544; Mon, 30 Apr 2007 22:10:19 -0700 (PDT) Received: by 10.114.72.4 with HTTP; Mon, 30 Apr 2007 22:10:19 -0700 (PDT) Message-ID: <1baa801f0704302210h3c391ba8ld0d9ce8d06088f43@mail.gmail.com> Date: Tue, 1 May 2007 07:10:19 +0200 From: "Alexandre Dulaunoy" To: syslog@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 11840536fac4fdea X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Syslog] geographic location in syslog - draft-dulaunoy-syslog-geolocation-00 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Dear, We had the need to add geographic meta information to syslog messages. Here is a draft : Title : geographic location in syslog Author(s) : A. Dulaunoy Filename : draft-dulaunoy-syslog-geolocation-00.txt Pages : 7 Date : 2007-4-30 http://www.ietf.org/internet-drafts/draft-dulaunoy-syslog-geolocation-00.txt Feel free to review and provide your comments. Thanks a lot, Best regards, _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue May 01 08:51:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hirow-00012w-7p; Tue, 01 May 2007 08:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hirov-00012r-8D for syslog@ietf.org; Tue, 01 May 2007 08:51:05 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hirou-0007VR-1h for syslog@ietf.org; Tue, 01 May 2007 08:51:05 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <200705011251030140025fnje>; Tue, 1 May 2007 12:51:03 +0000 From: "David Harrington" To: Date: Tue, 1 May 2007 08:50:50 -0400 Message-ID: <05ba01c78bef$58c02320$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceL7wP7FBWsOe2FS7GACNJGtuWE0Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Syslog] SDE proposals X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, As syslog WG co-chair, let me make the WG aware of this point. Standardization of structured data elements (SDEs) is out of scope for this WG. The syslog WG is a **security** WG, not a data modeling WG. The protocol document describes the fact that IANA-registered SDEs should be approved by Standards action. That is for (IETF-sponsored) IANA-registered SDEs only. Individuals can define their own SDEs (containing an at-sign) that are not IANA registered. We have had a couple drafts brought to this WG that define SDEs. If members of this WG want to standardize SDEs, they should request the creation of a WG in the OPS area to do that work, or if the SDEs relate to a specific type of SDEs, such as those related to RAI technologies, you might be abel to start a WG in the associated area. You will probably need to develop a charter, with document deliverables, timelines within which the documents will be delivered, and limits on which types of SDEs will be developed within the documents. Charters can be renewed to develop new documents for SDEs with different focus over time. Personally, I think defining and registering standard SDEs would be very valuable work. However, the syslog WG in the Security Area is not the correct WG to host this work. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue May 01 09:02:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1His0A-00083g-Ms; Tue, 01 May 2007 09:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1His0A-00081L-5c for syslog@ietf.org; Tue, 01 May 2007 09:02:42 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1His09-0000zq-Qz for syslog@ietf.org; Tue, 01 May 2007 09:02:42 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 01 May 2007 06:02:40 -0700 X-IronPort-AV: i="4.14,475,1170662400"; d="scan'208"; a="417396075:sNHT2639138968" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l41D2eVX024635; Tue, 1 May 2007 06:02:40 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l41D2ewo016073; Tue, 1 May 2007 13:02:40 GMT Date: Tue, 1 May 2007 06:02:39 -0700 (PDT) From: Chris Lonvick To: David Harrington Subject: Re: [Syslog] SDE proposals In-Reply-To: <05ba01c78bef$58c02320$0600a8c0@china.huawei.com> Message-ID: References: <05ba01c78bef$58c02320$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2597; t=1178024560; x=1178888560; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20SDE=20proposals |Sender:=20; bh=eIerO6XIgwViIWB60aY7LIgx9KmhhxvVHSM8iy9A7PY=; b=CVRhbcSfKxfHrwrEPhNyDIBDkS/M9E7Iz8WLzpGQH6OCQqEqZ4YHExcciTguj1lVQbAer9kI CvG753wDzg9nkTxVeash0vNVnZpduH3CvFA8uFntYqP7TvD5BYFF93rY; Authentication-Results: sj-dkim-6; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, David is correct in this. No matter how strongly we feel that defining SDEs for other applications is good work, it will not be done in this WG. For documents that describe new SDEs, the alternatives to forming a new WG are: - have SDEs defined in a WG that is already dealing with that application - produce individual contribution documents and get the support of an Area Director to turn them into RFCs. Please keep in mind that draft-ietf-syslog-protocol lists the "IETF Consensus" method for adding new SDEs. From RFC 2434: IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). Thanks, Chris On Tue, 1 May 2007, David Harrington wrote: > Hi, > > As syslog WG co-chair, let me make the WG aware of this point. > > Standardization of structured data elements (SDEs) is out of scope for > this WG. > The syslog WG is a **security** WG, not a data modeling WG. > > The protocol document describes the fact that IANA-registered SDEs > should be approved by Standards action. That is for (IETF-sponsored) > IANA-registered SDEs only. Individuals can define their own SDEs > (containing an at-sign) that are not IANA registered. > > We have had a couple drafts brought to this WG that define SDEs. If > members of this WG want to standardize SDEs, they should request the > creation of a WG in the OPS area to do that work, or if the SDEs > relate to a specific type of SDEs, such as those related to RAI > technologies, you might be abel to start a WG in the associated area. > You will probably need to develop a charter, with document > deliverables, timelines within which the documents will be delivered, > and limits on which types of SDEs will be developed within the > documents. Charters can be renewed to develop new documents for SDEs > with different focus over time. > > Personally, I think defining and registering standard SDEs would be > very valuable work. However, the syslog WG in the Security Area is not > the correct WG to host this work. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, syslog WG > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue May 01 14:46:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HixN8-0007GE-Qp; Tue, 01 May 2007 14:46:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiwio-0000lu-I7 for syslog@lists.ietf.org; Tue, 01 May 2007 14:05:06 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiwin-0003p1-67 for syslog@lists.ietf.org; Tue, 01 May 2007 14:05:06 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 1 May 2007 11:05:04 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Tue, 1 May 2007 11:05:04 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 May 2007 11:05:03 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] geographic location in syslog -draft-dulaunoy-syslog-geolocation-00 Date: Tue, 1 May 2007 11:04:25 -0700 Message-ID: <74735BF202608043B11025A9FAA9438905EB4C0B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <1baa801f0704302210h3c391ba8ld0d9ce8d06088f43@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] geographic location in syslog -draft-dulaunoy-syslog-geolocation-00 Thread-Index: AceLrwyvSoqQyULTSmuUHapRrp75XwAamZJA References: <1baa801f0704302210h3c391ba8ld0d9ce8d06088f43@mail.gmail.com> From: Eric Fitzgerald To: Alexandre Dulaunoy , X-OriginalArrivalTime: 01 May 2007 18:05:03.0910 (UTC) FILETIME=[3E364C60:01C78C1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Tue, 01 May 2007 14:46:45 -0400 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Alexandre, What is the use case for adding geographic meta data to syslog messages? Why should this be an RFC? Why would this not be payload (and therefore not part of any syslog standard)? Where would the data be sourced from, presumably a GPS attached to the device generating syslog messages? GPS typically output NMEA sentences, serialized as ASCII text. It might be easier computationally and standards-wise to adopt the appropriate NMEA sentence format, "GLL", and include that in the relevant syslog messages: http://www.gpsinformation.org/dale/nmea.htm#GLL. This solution would invalidate my next two comments. However GLL does not include altitude data so you would still have to account for that; currently GPS vendors use proprietary NMEA 0183 sentences for this purpose (there's information on the same page). The WGS 84 coordinate system referenced in the draft uses an X-Y-Z coordinate system, not latitude and longitude. You should explicitly call out that these are signed values and what valid sign characters are, etc., and not use "latitude" and "longitude". If you want to use latitude and longitude, the messages are missing cardinal compass direction references (N/S and E/W). Also altitude is presumably signed in this case. I hope this is helpful. Best regards, Eric Fitzgerald Microsoft Corporation -----Original Message----- From: Alexandre Dulaunoy [mailto:a@foo.be]=20 Sent: Monday, April 30, 2007 10:10 PM To: syslog@lists.ietf.org Subject: [Syslog] geographic location in syslog -draft-dulaunoy-syslog-geolocation-00 Dear, We had the need to add geographic meta information to syslog messages. Here is a draft : Title : geographic location in syslog Author(s) : A. Dulaunoy Filename : draft-dulaunoy-syslog-geolocation-00.txt Pages : 7 Date : 2007-4-30 =09 http://www.ietf.org/internet-drafts/draft-dulaunoy-syslog-geolocation-00 .txt Feel free to review and provide your comments. Thanks a lot, Best regards, _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed May 02 03:23:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj9BC-0008A5-Le; Wed, 02 May 2007 03:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj9B8-00082Q-NC; Wed, 02 May 2007 03:23:10 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj9B7-0008Qf-4Y; Wed, 02 May 2007 03:23:10 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007050207230801200347npe>; Wed, 2 May 2007 07:23:08 +0000 From: "David Harrington" To: Date: Wed, 2 May 2007 03:22:53 -0400 Message-ID: <06ae01c78c8a$b2cddd80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceMikB5L8xyDAJMTem9mf0p1W9DoA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: syslog@ietf.org Subject: [Syslog] syslog data modeling X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I propose that an initial set of syslog data models be developed in the OPS Area WG. For those who have not followed the work of the syslog WG, let me explain. The syslog WG in the security area has drawn a number of syslog implementers to work on standardizing the message format for syslog, as an important step toward addressing security issues. The syslog WG is scoped to address "security issues in network event logging", and the work is drawing to a close, as three of the documents in its charter (a message format and UDP and TLS transport mappings) are being delivered for IESG consideration as Proposed Standards, and the other three (a reliable transport mapping, an integrity-checking "signature" mechanism, and a MIB module) are scheduled for WGLC within the next two months. The co-chairs expect that the syslog WG will close by year-end. One of the features of the new message format is structured data elements (SDEs), which provide a mechanism for structuring message content so it is more easily parsed by programs/tools. The SDE format supplements the traditional free-form text content. There are some proposals starting to be published for SDEs and posted to the syslog WG, such as SDEs that map syslog severity to ITU-T perceived severities, following the work done in the ALARM-MIB. The co-chairs believe it would be inappropriate for the "security issues in network event logging" WG to deal with proposals for syslog data modeling. The OPS area would be the likely area to work on data modeling standards for syslog. A few SDEs have been defined by the syslog WG that are used in the syslog message header, but we have not addressed the many SDEs that could be included in syslog content. It would be good to design a set of SDEs that are consistent with other IETF protocol information models and data models, such as MIB-II, IF-MIB, ENTITY-MIB, standard SNMP notification-types, and standard netconf data models, to make it easier for operators to correlate the information in syslog messages with the information contained in SNMP trap and informs and in netconf notifications, and possibly ipfix information elements. The experts in these IETF-based information and data models are found in the OPS area. I propose that an initial set of SDEs be worked on within the OPSAWG. The scope and deliverables of such work should be clearly defined based on the correlation needs of operators, input from network management modeling experts in the OPS area, in cooperation with the syslog implementers from the current syslog WG. If you agree and would be willing to work on developing standardized SDEs for syslog, please email me at ietfdbh@comcast.net. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed May 02 11:45:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjH1C-0007jN-TF; Wed, 02 May 2007 11:45:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjGgi-00087y-V5 for syslog@ietf.org; Wed, 02 May 2007 11:24:16 -0400 Received: from smtp102.sbc.mail.mud.yahoo.com ([68.142.198.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjGgh-0007mv-1z for syslog@ietf.org; Wed, 02 May 2007 11:24:16 -0400 Received: (qmail 24929 invoked from network); 2 May 2007 15:24:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.242 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 2 May 2007 15:24:14 -0000 X-YMail-OSG: ifRvQs4VM1ktYWGaGp8TjBpXvMMaq2HXvqnq.e3onLK9dcqqfZGH9y3I5yYKXjuzUw6RAbuAT3RWth8byEvMWVPqYw-- Message-ID: <4638ACFA.8010303@andybierman.com> Date: Wed, 02 May 2007 08:23:38 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: David Harrington References: <06ae01c78c8a$b2cddd80$0600a8c0@china.huawei.com> In-Reply-To: <06ae01c78c8a$b2cddd80$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-Mailman-Approved-At: Wed, 02 May 2007 11:45:25 -0400 Cc: syslog@ietf.org, ops-area@ietf.org Subject: [Syslog] Re: [OPS-AREA] syslog data modeling X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David Harrington wrote: > Hi, > > I propose that an initial set of syslog data models be developed in > the OPS Area WG. Are you suggesting a set of standard SDEs for particular MIB objects, or the SDE encoding rules for an arbitrary MIB object? Or both? Andy > > For those who have not followed the work of the syslog WG, let me > explain. > > The syslog WG in the security area has drawn a number of syslog > implementers to work on standardizing the message format for syslog, > as an important step toward addressing security issues. The syslog WG > is scoped to address "security issues in network event logging", and > the work is drawing to a close, as three of the documents in its > charter (a message format and UDP and TLS transport mappings) are > being delivered for IESG consideration as Proposed Standards, and the > other three (a reliable transport mapping, an integrity-checking > "signature" mechanism, and a MIB module) are scheduled for WGLC within > the next two months. The co-chairs expect that the syslog WG will > close by year-end. > > One of the features of the new message format is structured data > elements (SDEs), which provide a mechanism for structuring message > content so it is more easily parsed by programs/tools. The SDE format > supplements the traditional free-form text content. There are some > proposals starting to be published for SDEs and posted to the syslog > WG, such as SDEs that map syslog severity to ITU-T perceived > severities, following the work done in the ALARM-MIB. > > The co-chairs believe it would be inappropriate for the "security > issues in network event logging" WG to deal with proposals for syslog > data modeling. The OPS area would be the likely area to work on data > modeling standards for syslog. > > A few SDEs have been defined by the syslog WG that are used in the > syslog message header, but we have not addressed the many SDEs that > could be included in syslog content. It would be good to design a set > of SDEs that are consistent with other IETF protocol information > models and data models, such as MIB-II, IF-MIB, ENTITY-MIB, standard > SNMP notification-types, and standard netconf data models, to make it > easier for operators to correlate the information in syslog messages > with the information contained in SNMP trap and informs and in netconf > notifications, and possibly ipfix information elements. The experts in > these IETF-based information and data models are found in the OPS > area. > > I propose that an initial set of SDEs be worked on within the OPSAWG. > The scope and deliverables of such work should be clearly defined > based on the correlation needs of operators, input from network > management modeling experts in the OPS area, in cooperation with the > syslog implementers from the current syslog WG. > > If you agree and would be willing to work on developing standardized > SDEs for syslog, please email me at ietfdbh@comcast.net. > > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed May 02 11:47:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjH35-00087v-RR; Wed, 02 May 2007 11:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjH34-00087Q-Ht; Wed, 02 May 2007 11:47:22 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjH32-0003RX-84; Wed, 02 May 2007 11:47:22 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 42F1576892; Wed, 2 May 2007 17:47:19 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12983-06; Wed, 2 May 2007 17:47:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 85A4F765D1; Wed, 2 May 2007 17:46:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 788532427B9; Wed, 2 May 2007 17:46:46 +0200 (CEST) Date: Wed, 2 May 2007 17:46:46 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20070502154646.GA22432@elstar.local> Mail-Followup-To: Andy Bierman , David Harrington , syslog@ietf.org, ops-area@ietf.org References: <06ae01c78c8a$b2cddd80$0600a8c0@china.huawei.com> <4638ACFA.8010303@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4638ACFA.8010303@andybierman.com> User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: syslog@ietf.org, ops-area@ietf.org Subject: [Syslog] Re: [OPS-AREA] syslog data modeling X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, May 02, 2007 at 08:23:38AM -0700, Andy Bierman wrote: > Are you suggesting a set of standard SDEs for particular MIB objects, > or the SDE encoding rules for an arbitrary MIB object? Or both? draft-marinov-syslog-snmp-00.txt suggests a number SDs that can wrap arbitrary SNMP notifications in a syslog message. Note that SNMP notification to syslog translators are widely deployed and our idea was simply to provide a lossless common way for doing this. /js PS: Do we really have to do this cross-posting thing? Can we host this discussion in a single place? -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed May 02 11:58:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjHDb-0002B5-O2; Wed, 02 May 2007 11:58:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjHCo-0000zg-CE; Wed, 02 May 2007 11:57:26 -0400 Received: from smtpproxy2.mitre.org ([192.80.55.71] helo=smtp-mclean.mitre.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjHCm-0005SC-Vh; Wed, 02 May 2007 11:57:26 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l42Fq08l028328; Wed, 2 May 2007 11:52:00 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id EE6DE4F8D9; Wed, 2 May 2007 11:51:59 -0400 (EDT) Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l42FpxcG028272; Wed, 2 May 2007 11:51:59 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 11:57:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 May 2007 11:57:23 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F01C9BAE5@IMCSRV2.MITRE.ORG> In-Reply-To: <4638ACFA.8010303@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] syslog data modeling Thread-Index: AceMzfhLMLQNkh2ATTmk5PE9DdhbSAAAKWYg References: <06ae01c78c8a$b2cddd80$0600a8c0@china.huawei.com> <4638ACFA.8010303@andybierman.com> From: "Natale, Bob" To: "David Harrington" X-OriginalArrivalTime: 02 May 2007 15:57:23.0966 (UTC) FILETIME=[92F159E0:01C78CD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-Mailman-Approved-At: Wed, 02 May 2007 11:58:14 -0400 Cc: syslog@ietf.org, Andy Bierman , ops-area@ietf.org Subject: [Syslog] RE: [OPS-AREA] syslog data modeling X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Dave, The same question that Andy asks below occurred to me when I read your note...since I have not followed the "Security Issues in Syslog" WG for some time, I checked the WG charter page and the additional info at http://www.employees.org/~lonvick/index.shtml ...and came away a bit confused about the MIB work being done there ...this confusion is still based on flimsy research, so I won't whine about a smack on the wrist if warranted. :) However, the charter calls for a Syslog Device MIB...the current version of the I-D appears to be at http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-15.txt ...but that MIB seems to be about control and monitoring of Syslog applications (nothing wrong with that!...quite the contrary) ...notes indicate that the change was made at -11 (the descriptive text on the "Additional Info" page should be updated accordingly) ...changes "process" and "device" to "entity" =3D=3D "application"...fine. But what IETF MIB refers to Syslog messages themselves...along the lines of, for example, the CISCO-SYSLOG-MIB...? Cheers, BobN -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Wednesday, May 02, 2007 11:24 AM To: David Harrington Cc: syslog@ietf.org; ops-area@ietf.org Subject: Re: [OPS-AREA] syslog data modeling David Harrington wrote: > Hi, >=20 > I propose that an initial set of syslog data models be developed in > the OPS Area WG. Are you suggesting a set of standard SDEs for particular MIB objects, or the SDE encoding rules for an arbitrary MIB object? Or both? Andy >=20 > For those who have not followed the work of the syslog WG, let me > explain. >=20 > The syslog WG in the security area has drawn a number of syslog > implementers to work on standardizing the message format for syslog, > as an important step toward addressing security issues. The syslog WG > is scoped to address "security issues in network event logging", and > the work is drawing to a close, as three of the documents in its > charter (a message format and UDP and TLS transport mappings) are > being delivered for IESG consideration as Proposed Standards, and the > other three (a reliable transport mapping, an integrity-checking > "signature" mechanism, and a MIB module) are scheduled for WGLC within > the next two months. The co-chairs expect that the syslog WG will > close by year-end. >=20 > One of the features of the new message format is structured data > elements (SDEs), which provide a mechanism for structuring message > content so it is more easily parsed by programs/tools. The SDE format > supplements the traditional free-form text content. There are some > proposals starting to be published for SDEs and posted to the syslog > WG, such as SDEs that map syslog severity to ITU-T perceived > severities, following the work done in the ALARM-MIB.=20 >=20 > The co-chairs believe it would be inappropriate for the "security > issues in network event logging" WG to deal with proposals for syslog > data modeling. The OPS area would be the likely area to work on data > modeling standards for syslog.=20 >=20 > A few SDEs have been defined by the syslog WG that are used in the > syslog message header, but we have not addressed the many SDEs that > could be included in syslog content. It would be good to design a set > of SDEs that are consistent with other IETF protocol information > models and data models, such as MIB-II, IF-MIB, ENTITY-MIB, standard > SNMP notification-types, and standard netconf data models, to make it > easier for operators to correlate the information in syslog messages > with the information contained in SNMP trap and informs and in netconf > notifications, and possibly ipfix information elements. The experts in > these IETF-based information and data models are found in the OPS > area.=20 >=20 > I propose that an initial set of SDEs be worked on within the OPSAWG. > The scope and deliverables of such work should be clearly defined > based on the correlation needs of operators, input from network > management modeling experts in the OPS area, in cooperation with the > syslog implementers from the current syslog WG.=20 >=20 > If you agree and would be willing to work on developing standardized > SDEs for syslog, please email me at ietfdbh@comcast.net. >=20 >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area >=20 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed May 02 12:25:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjHdl-0006QH-KU; Wed, 02 May 2007 12:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjHdj-0006LD-Nl for syslog@lists.ietf.org; Wed, 02 May 2007 12:25:15 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjHdf-0002Ji-7Z for syslog@lists.ietf.org; Wed, 02 May 2007 12:25:15 -0400 Received: by nz-out-0506.google.com with SMTP id o37so229019nzf for ; Wed, 02 May 2007 09:25:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=MeFu9X6bikSMlYvDW+aGww+oRfYCUgjQOr+hwLBUtkqUakdFoG/r4ZwpCUKsu7EtqXKCHPJmFJyxhQV9Bgr+lF4pSp80TBYVuPjLPCtLBMOvX8DU83iFZed3ASX5AJJ+xJtCFJZjHHWwoZZkW+t8PAARDjg2jGSvxc3WljkIqz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=NBs8flRKCRJg+LbncaTQYzpMSff4a3ZI8tkgq4tOTIUAjeDgzv6C/7HpHO8C19vURBFA+JH8QlEhNSjlMDPehQfyl2g934CvaFQcMMgOCQx87oPmIBGJu25Gf2eNavx7+PQm1uGrPBT/B7dFMBQT/tu+yzF6wuUrB3mOvGNqgZg= Received: by 10.114.122.2 with SMTP id u2mr279358wac.1178123110224; Wed, 02 May 2007 09:25:10 -0700 (PDT) Received: by 10.114.94.12 with HTTP; Wed, 2 May 2007 09:25:10 -0700 (PDT) Message-ID: Date: Wed, 2 May 2007 09:25:10 -0700 From: "Anton Chuvakin" To: "Alexandre Dulaunoy" , syslog@lists.ietf.org Subject: Re: [Syslog] geographic location in syslog -draft-dulaunoy-syslog-geolocation-00 In-Reply-To: <74735BF202608043B11025A9FAA9438905EB4C0B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 References: <1baa801f0704302210h3c391ba8ld0d9ce8d06088f43@mail.gmail.com> <74735BF202608043B11025A9FAA9438905EB4C0B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-Google-Sender-Auth: 5c8782e1a619ff03 X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0546777799==" Errors-To: syslog-bounces@lists.ietf.org --===============0546777799== Content-Type: multipart/alternative; boundary="----=_Part_8433_3653835.1178123110163" ------=_Part_8433_3653835.1178123110163 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It sounds kinda bizarre to me too... I though geo lookups can be handled elewhere.. On 5/1/07, Eric Fitzgerald wrote: > > Hi Alexandre, > > What is the use case for adding geographic meta data to syslog messages? > Why should this be an RFC? > > Why would this not be payload (and therefore not part of any syslog > standard)? > > Where would the data be sourced from, presumably a GPS attached to the > device generating syslog messages? > > GPS typically output NMEA sentences, serialized as ASCII text. It might > be easier computationally and standards-wise to adopt the appropriate > NMEA sentence format, "GLL", and include that in the relevant syslog > messages: http://www.gpsinformation.org/dale/nmea.htm#GLL. This > solution would invalidate my next two comments. However GLL does not > include altitude data so you would still have to account for that; > currently GPS vendors use proprietary NMEA 0183 sentences for this > purpose (there's information on the same page). > > The WGS 84 coordinate system referenced in the draft uses an X-Y-Z > coordinate system, not latitude and longitude. You should explicitly > call out that these are signed values and what valid sign characters > are, etc., and not use "latitude" and "longitude". > > If you want to use latitude and longitude, the messages are missing > cardinal compass direction references (N/S and E/W). Also altitude is > presumably signed in this case. > > I hope this is helpful. > > Best regards, > Eric Fitzgerald > Microsoft Corporation > > -----Original Message----- > From: Alexandre Dulaunoy [mailto:a@foo.be] > Sent: Monday, April 30, 2007 10:10 PM > To: syslog@lists.ietf.org > Subject: [Syslog] geographic location in syslog > -draft-dulaunoy-syslog-geolocation-00 > > Dear, > > We had the need to add geographic meta information to syslog messages. > > Here is a draft : > > Title : geographic location in syslog > Author(s) : A. Dulaunoy > Filename : draft-dulaunoy-syslog-geolocation-00.txt > Pages : 7 > Date : 2007-4-30 > > http://www.ietf.org/internet-drafts/draft-dulaunoy-syslog-geolocation-00 > .txt > > Feel free to review and provide your comments. > > Thanks a lot, > > Best regards, > > _______________________________________________ > 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 > -- Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA http://www.chuvakin.org http://chuvakin.blogspot.com http://www.info-secure.org ------=_Part_8433_3653835.1178123110163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline It sounds kinda bizarre to me too... I though geo lookups can be handled elewhere..

On 5/1/07, Eric Fitzgerald < Eric.Fitzgerald@microsoft.com> wrote:
Hi Alexandre,

What is the use case for adding geographic meta data to syslog messages?
Why should this be an RFC?

Why would this not be payload (and therefore not part of any syslog
standard)?

Where would the data be sourced from, presumably a GPS attached to the
device generating syslog messages?

GPS typically output NMEA sentences, serialized as ASCII text.  It might
be easier computationally and standards-wise to adopt the appropriate
NMEA sentence format, "GLL", and include that in the relevant syslog
messages: http://www.gpsinformation.org/dale/nmea.htm#GLL.  This
solution would invalidate my next two comments.  However GLL does not
include altitude data so you would still have to account for that;
currently GPS vendors use proprietary NMEA 0183 sentences for this
purpose (there's information on the same page).

The WGS 84 coordinate system referenced in the draft uses an X-Y-Z
coordinate system, not latitude and longitude.  You should explicitly
call out that these are signed values and what valid sign characters
are, etc., and not use "latitude" and "longitude".

If you want to use latitude and longitude, the messages are missing
cardinal compass direction references (N/S and E/W).  Also altitude is
presumably signed in this case.

I hope this is helpful.

Best regards,
Eric Fitzgerald
Microsoft Corporation

-----Original Message-----
From: Alexandre Dulaunoy [mailto:a@foo.be]
Sent: Monday, April 30, 2007 10:10 PM
To: syslog@lists.ietf.org
Subject: [Syslog] geographic location in syslog
-draft-dulaunoy-syslog-geolocation-00

Dear,

We had the need to add geographic meta information to syslog messages.

Here is a draft :

        Title           : geographic location in syslog
        Author(s)       : A. Dulaunoy
        Filename        : draft-dulaunoy-syslog-geolocation-00.txt
        Pages           : 7
        Date            : 2007-4-30

http://www.ietf.org/internet-drafts/draft-dulaunoy-syslog-geolocation-00
.txt

Feel free to review and provide your comments.

Thanks a lot,

Best regards,

_______________________________________________
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



--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
      http://www.chuvakin.org
  http://chuvakin.blogspot.com
    http://www.info-secure.org ------=_Part_8433_3653835.1178123110163-- --===============0546777799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --===============0546777799==-- From syslog-bounces@lists.ietf.org Wed May 02 13:45:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjIt1-0004BH-AZ; Wed, 02 May 2007 13:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjIsz-00049U-ID; Wed, 02 May 2007 13:45:05 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjIsy-0002Oe-BE; Wed, 02 May 2007 13:45:05 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <20070502174503013003h3epe>; Wed, 2 May 2007 17:45:03 +0000 From: "David Harrington" To: , "'Andy Bierman'" References: <06ae01c78c8a$b2cddd80$0600a8c0@china.huawei.com> <4638ACFA.8010303@andybierman.com> <20070502154646.GA22432@elstar.local> Date: Wed, 2 May 2007 13:44:46 -0400 Message-ID: <06ea01c78ce1$93753210$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070502154646.GA22432@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceM0Srzi9UPzll2SGimT6PfrDAGuwAD6Z+Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: syslog@ietf.org, ops-area@ietf.org Subject: [Syslog] RE: [OPS-AREA] syslog data modeling X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org My proposal was to do this work in the OPS area, and I recommend discussing this on the OPS area mailing list, rather than cross-posting. After this message, I plan to drop the syslog WG from the To: and CC: fields. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Wednesday, May 02, 2007 11:47 AM > To: Andy Bierman > Cc: David Harrington; syslog@ietf.org; ops-area@ietf.org > Subject: Re: [OPS-AREA] syslog data modeling > > On Wed, May 02, 2007 at 08:23:38AM -0700, Andy Bierman wrote: > > > Are you suggesting a set of standard SDEs for particular > MIB objects, > > or the SDE encoding rules for an arbitrary MIB object? Or both? > > draft-marinov-syslog-snmp-00.txt suggests a number SDs that can wrap > arbitrary SNMP notifications in a syslog message. Note that SNMP > notification to syslog translators are widely deployed and our idea > was simply to provide a lossless common way for doing this. > > /js > > PS: Do we really have to do this cross-posting thing? Can we host this > discussion in a single place? > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed May 02 15:50:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpx-0007fB-RB; Wed, 02 May 2007 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0007dy-Rq; Wed, 02 May 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0003AK-HW; Wed, 02 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7E41332955; Wed, 2 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HjKpu-0005ih-DJ; Wed, 02 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 02 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-20.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-20.txt Pages : 38 Date : 2007-5-2 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the anticipated original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a standards- track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-20.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-20.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-20.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-2105817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-2105817.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Wed May 02 16:45:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjLhu-0001cV-Tk; Wed, 02 May 2007 16:45:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjLht-0001bQ-7C for syslog@ietf.org; Wed, 02 May 2007 16:45:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjLhr-0004nv-Rn for syslog@ietf.org; Wed, 02 May 2007 16:45:49 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 02 May 2007 13:45:48 -0700 X-IronPort-AV: i="4.14,482,1170662400"; d="scan'208"; a="417974538:sNHT44745428" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l42KjlXI028721 for ; Wed, 2 May 2007 13:45:47 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l42KjlA9010665 for ; Wed, 2 May 2007 20:45:47 GMT Date: Wed, 2 May 2007 13:45:46 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2113; t=1178138747; x=1179002747; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20FINAL=20review=20of=20draft-ietf-syslog-protocol |Sender:=20; bh=aJ0fNLJ1qhk3+jsTsXCI+qsGiwVAjGOY6TIV8LNGPpc=; b=aJidULANDf6otYuq+jBKNBcirpN4TvORivZSbZJsvsdgB8jsngPqkxf2kzWAHFv725Mb5jec EwjREJ4s8oFTY2dg87eR9N8OsbR3U2SSJ7VU/w9rCH1y58vMRU2QQoHN; Authentication-Results: sj-dkim-7; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Syslog] FINAL review of draft-ietf-syslog-protocol X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, David and I would like to hand off this final version to Sam for publication by Friday. I have performed an initial review and feel that the changes address the IETF Last Call items. The changes requested from the IETF Last Call were: Item 1) Severity Range - The range of the Severity is not bound. The WG decided that it needs to be bound in the range of 0 to 7 inclusive. Item 2) Language Tags - BCP47 (RFC 4646) is the IETF standard for language tags. The document needs to be compliant with this standard. Section 7.3.3 specifies the use of ISO 639 (which was the only reference available at the time we discussed languages in the mailing list.) Sam asked that we need to change the language tags to BCP47 to justify our decision. I've found no compelling reason to continue to use the ISO 639 tags. We need to change that paragraph to state that BCP47 language tags will be used. The current "MAY" in Section 7.3.3 should still be used. Item 3 - Deadlocks - There was a lengthy discussion about using a reliable delivery mechanism for syslog and how certain circumstances could cause the loss of messages. (I personally felt it was not addressing any normative text in the document.) A note about "deadlocks" in Section 8.5 has been requested by Sam. This will need to be short. Item 4 - IANA - We should review the document to see if there are any IANA registry values that may be revised by IETF Consensus rather than Standards Actions. I'll make a review and let you know if I find anything. Item 5 - Definitions - The definitions of "sender" "receiver" "relay", "originator" and "collector" need to be tightened up. They are somewhat inconsistent now and are required by the -device-mib document. You may view the differences between -19 and -20 here: http://tools.ietf.org/wg/syslog/ Click on "draft-ietf-syslog-protocol" and select your method of seeing the diffs from -19. Please submit any comments you have to the WG that concern how Rainer addressed these issues in this document. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed May 02 19:06:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjNu1-0004t4-Pp; Wed, 02 May 2007 19:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjNu0-0004sr-2d; Wed, 02 May 2007 19:06:28 -0400 Received: from mga07.intel.com ([143.182.124.22] helo=azsmga101.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjNty-00046D-E6; Wed, 02 May 2007 19:06:28 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 02 May 2007 16:06:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.14,482,1170662400"; d="txt'208?scan'208,208";a="223382829" Received: from fmsmsxpoc001.fm.intel.com (HELO fmsmsxpoc001.amr.corp.intel.com) ([132.233.49.22]) by azsmga001.ch.intel.com with ESMTP; 02 May 2007 16:06:23 -0700 Received: from fmsmsx334.amr.corp.intel.com (132.233.42.1) by fmsmsxpoc001.amr.corp.intel.com (132.233.49.22) with Microsoft SMTP Server id 8.0.685.24; Wed, 2 May 2007 15:32:43 -0700 Received: from fmsmsx413.amr.corp.intel.com ([10.19.19.5]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 15:06:17 -0700 Received: from mail pickup service by fmsmsx413.amr.corp.intel.com with Microsoft SMTPSVC; Wed, 2 May 2007 15:06:12 -0700 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmsx413.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 12:53:06 -0700 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 12:53:05 -0700 Received: from lists.smithbucklin.com (HELO fmsmga101.fm.intel.com) ([206.69.81.56]) by fmsmga001-1.fm.intel.com with ESMTP; 02 May 2007 12:53:03 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFiJOEacmhCRkmdsb2JhbACBZI00ewIBAQcOBQgd X-IronPort-AV: E=Sophos;i="4.14,482,1170662400"; d="txt'208?scan'208,208";a="222282267" Received: from odin.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by mga01.intel.com with ESMTP; 02 May 2007 12:52:42 -0700 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpw-0007et-MG; Wed, 02 May 2007 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0007dy-Rq; Wed, 02 May 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0003AK-HW; Wed, 02 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7E41332955; Wed, 2 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HjKpu-0005ih-DJ; Wed, 02 May 2007 15:50:02 -0400 Content-Type: multipart/mixed; boundary="NextPart" MIME-Version: 1.0 To: i-d-announce@ietf.org From: Message-ID: Date: Wed, 2 May 2007 15:50:02 -0400 X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 02 May 2007 19:53:05.0973 (UTC) FILETIME=[803C5E50:01C78CF3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-20.txt X-BeenThere: syslog@lists.ietf.org Reply-To: internet-drafts@ietf.org List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-20.txt Pages : 38 Date : 2007-5-2 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the anticipated original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a standards- track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-20.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-20.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-20.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: multipart/alternative; boundary="OtherAccess" --OtherAccess Content-Type: message/external-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-2105817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-20.txt --OtherAccess Content-Type: message/external-body; name="draft-ietf-syslog-protocol-20.txt"; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-Type: text/plain Content-ID: <2007-5-2105817.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Fri May 04 04:35:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjtFs-0002SK-0f; Fri, 04 May 2007 04:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjtFq-0002C0-5D for syslog@ietf.org; Fri, 04 May 2007 04:35:06 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjtDg-0001Rp-VX for syslog@ietf.org; Fri, 04 May 2007 04:32:55 -0400 Received: from pc6 (1Cust174.tnt14.lnd4.gbr.da.uu.net [62.188.143.174]) by astro.systems.pipex.net (Postfix) with SMTP id 9D349E0000DC; Fri, 4 May 2007 09:32:48 +0100 (BST) Message-ID: <002001c78e1d$f1656ba0$0601a8c0@pc6> From: "tom.petch" To: "Natale, Bob" References: <06ae01c78c8a$b2cddd80$0600a8c0@china.huawei.com><4638ACFA.8010303@andybierman.com> <4915F014FDD99049A9C3A8C1B832004F01C9BAE5@IMCSRV2.MITRE.ORG> Subject: Re: [Syslog] RE: [OPS-AREA] syslog data modeling Date: Fri, 4 May 2007 09:28:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Natale, Bob" To: "David Harrington" Cc: ; "Andy Bierman" ; Sent: Wednesday, May 02, 2007 5:57 PM Subject: [Syslog] RE: [OPS-AREA] syslog data modeling Hi Dave, The same question that Andy asks below occurred to me when I read your note...since I have not followed the "Security Issues in Syslog" WG for some time, I checked the WG charter page and the additional info at http://www.employees.org/~lonvick/index.shtml ...and came away a bit confused about the MIB work being done there ...this confusion is still based on flimsy research, so I won't whine about a smack on the wrist if warranted. :) However, the charter calls for a Syslog Device MIB...the current version of the I-D appears to be at http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-15.txt ...but that MIB seems to be about control and monitoring of Syslog applications (nothing wrong with that!...quite the contrary) ...notes indicate that the change was made at -11 (the descriptive text on the "Additional Info" page should be updated accordingly) ...changes "process" and "device" to "entity" == "application"...fine. But what IETF MIB refers to Syslog messages themselves...along the lines of, for example, the CISCO-SYSLOG-MIB...? Bob I may be able to shed some light on this. Syslog messages are processed by thingies (bear with me and you will understand my choice of this technical term) which can be looked at in plan view, as sender, receiver or store-and-forward; or in elevation, as transport, session, presentation and such like. The terminology for these looks includes "sender" "receiver" "relay", "originator", "collector", "device", "entity", "process", "application", "facility" "sysloghost", "generator", "syslogserver"; in fact, anything but "thingie" with perhaps "device" being the commonest (after all, what else does the d in syslogd stand for :-) The same term can mean different things in different places and a different term may or may not mean the same thing elsewhere. The change you note in syslog-mib-11 was intended to make it more likely that there is a one to one mapping of concept to term across the set of I-Ds that the WG is producing, and was not a change in the information modelled by the mib module. I agree that proprietary mib modules take a different view of what should be modelled - closer for example to the work of disman - but in this regard, the syslog mib module has been consistent, focussing more on the lower layers of the stack. Tom Petch Cheers, BobN -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Wednesday, May 02, 2007 11:24 AM To: David Harrington Cc: syslog@ietf.org; ops-area@ietf.org Subject: Re: [OPS-AREA] syslog data modeling David Harrington wrote: > Hi, > > I propose that an initial set of syslog data models be developed in > the OPS Area WG. Are you suggesting a set of standard SDEs for particular MIB objects, or the SDE encoding rules for an arbitrary MIB object? Or both? Andy > > For those who have not followed the work of the syslog WG, let me > explain. > > The syslog WG in the security area has drawn a number of syslog > implementers to work on standardizing the message format for syslog, > as an important step toward addressing security issues. The syslog WG > is scoped to address "security issues in network event logging", and > the work is drawing to a close, as three of the documents in its > charter (a message format and UDP and TLS transport mappings) are > being delivered for IESG consideration as Proposed Standards, and the > other three (a reliable transport mapping, an integrity-checking > "signature" mechanism, and a MIB module) are scheduled for WGLC within > the next two months. The co-chairs expect that the syslog WG will > close by year-end. > > One of the features of the new message format is structured data > elements (SDEs), which provide a mechanism for structuring message > content so it is more easily parsed by programs/tools. The SDE format > supplements the traditional free-form text content. There are some > proposals starting to be published for SDEs and posted to the syslog > WG, such as SDEs that map syslog severity to ITU-T perceived > severities, following the work done in the ALARM-MIB. > > The co-chairs believe it would be inappropriate for the "security > issues in network event logging" WG to deal with proposals for syslog > data modeling. The OPS area would be the likely area to work on data > modeling standards for syslog. > > A few SDEs have been defined by the syslog WG that are used in the > syslog message header, but we have not addressed the many SDEs that > could be included in syslog content. It would be good to design a set > of SDEs that are consistent with other IETF protocol information > models and data models, such as MIB-II, IF-MIB, ENTITY-MIB, standard > SNMP notification-types, and standard netconf data models, to make it > easier for operators to correlate the information in syslog messages > with the information contained in SNMP trap and informs and in netconf > notifications, and possibly ipfix information elements. The experts in > these IETF-based information and data models are found in the OPS > area. > > I propose that an initial set of SDEs be worked on within the OPSAWG. > The scope and deliverables of such work should be clearly defined > based on the correlation needs of operators, input from network > management modeling experts in the OPS area, in cooperation with the > syslog implementers from the current syslog WG. > > If you agree and would be willing to work on developing standardized > SDEs for syslog, please email me at ietfdbh@comcast.net. > > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri May 04 11:41:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjzuZ-0003VY-Hi; Fri, 04 May 2007 11:41:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjzuY-0003Rk-3i for syslog@ietf.org; Fri, 04 May 2007 11:41:34 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjzuW-0003CH-LF for syslog@ietf.org; Fri, 04 May 2007 11:41:34 -0400 Received: from pc6 (1Cust187.tnt29.lnd3.gbr.da.uu.net [62.188.120.187]) by blaster.systems.pipex.net (Postfix) with SMTP id 1D949E000607; Fri, 4 May 2007 16:41:29 +0100 (BST) Message-ID: <000b01c78e59$d3faa1c0$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol Date: Fri, 4 May 2007 16:37:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris I have looked at this and will look at it again in more depth next week. Some of the new terminology in s.3 is unfamiliar to me and, while the end result is not as complex as say RFC3411, it is still going to take a while for me to grasp (by inference) the role of eg parser and formatter, the (redefined) sender and receiver, and to work out which is responsible for which bits on the wire and see if the usage hangs together. The changes are more extensive than I anticipated. Probably, they much improve the precision but, at first sight, I am less certain about the increase in clarity. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Wednesday, May 02, 2007 10:45 PM Subject: [Syslog] FINAL review of draft-ietf-syslog-protocol > Hi Folks, > > David and I would like to hand off this final version to Sam for > publication by Friday. I have performed an initial review and feel that > the changes address the IETF Last Call items. > > The changes requested from the IETF Last Call were: > > Item 1) Severity Range - The range of the Severity is not bound. The WG > decided that it needs to be bound in the range of 0 to 7 inclusive. > > Item 2) Language Tags - BCP47 (RFC 4646) is the IETF standard for language > tags. The document needs to be compliant with this standard. Section > 7.3.3 specifies the use of ISO 639 (which was the only reference available > at the time we discussed languages in the mailing list.) Sam asked that > we need to change the language tags to BCP47 to justify our decision. I've > found no compelling reason to continue to use the ISO 639 tags. We need > to change that paragraph to state that BCP47 language tags will be used. > The current "MAY" in Section 7.3.3 should still be used. > > Item 3 - Deadlocks - There was a lengthy discussion about using a reliable > delivery mechanism for syslog and how certain circumstances could cause > the loss of messages. (I personally felt it was not addressing any > normative text in the document.) A note about "deadlocks" in Section 8.5 > has been requested by Sam. This will need to be short. > > Item 4 - IANA - We should review the document to see if there are any IANA > registry values that may be revised by IETF Consensus rather than > Standards Actions. I'll make a review and let you know if I find > anything. > > Item 5 - Definitions - The definitions of "sender" "receiver" "relay", > "originator" and "collector" need to be tightened up. They are somewhat > inconsistent now and are required by the -device-mib document. > > > You may view the differences between -19 and -20 here: > http://tools.ietf.org/wg/syslog/ > Click on "draft-ietf-syslog-protocol" and select your method of seeing the > diffs from -19. > > Please submit any comments you have to the WG that concern how Rainer > addressed these issues in this document. > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun May 06 11:09:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkiMD-0007yi-I5; Sun, 06 May 2007 11:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkiMC-0007ya-VJ; Sun, 06 May 2007 11:09:04 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkiMB-00033u-Re; Sun, 06 May 2007 11:09:04 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm10c463df4cf; Sun, 06 May 2007 23:20:03 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm9463901f1; Thr, 03 May 2007 04:06:15 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 03 May 2007 04:06:15 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpx-0007et-BR; Wed, 02 May 2007 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0007dy-Rq; Wed, 02 May 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0003AK-HW; Wed, 02 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7E41332955; Wed, 2 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HjKpu-0005ih-DJ; Wed, 02 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 02 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-20.txt X-BeenThere: syslog@lists.ietf.org Reply-To: internet-drafts@ietf.org List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-20.txt Pages : 38 Date : 2007-5-2 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the anticipated original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a standards- track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-20.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-20.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-20.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-2105817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-2105817.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From necojp@citiz.net Thu May 10 15:06:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDyb-0003e3-W9 for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Thu, 10 May 2007 15:06:57 -0400 Received: from [222.168.181.197] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDyZ-0007iR-SP for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Thu, 10 May 2007 15:06:57 -0400 Received: from ucbmu5 (unknown [125.145.141.24]) by smtp38 (Coremail) with SMTP id a9Qn22QaJLpUKlYP.1 for ; Sun, 02 May 2004 12:22:48 +0800 (CST) X-Originating-IP: [125.145.141.24] Subject: =?iso-2022-jp?B?GyRCIiM/TTpKSVROUTdHPChIRBsoQiA=?= From: =?shift-jis?B?b3NoaXJhc2U=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C78F4B.56699E30" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C78F4B.56699E30 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B"#?M:J!&e$,$k=O=w$NFyM_!"l$rL5NA$GDs6!$7$F$$$^$9!#(B $BITNQ$G$-$k?M:J$O$3$3!*(B 18$B:PL$K~$O$4MxMQ$G$-$^$;$s!#(B http://www.10wn.com/h/?wls $B!Z?M:J![%(%C%A$J?M:J$HITNQ$N=P2q$$(B $B!!(B $B!yC6Fa!&:J$NIb5$(B $B!y4{:'$K!VG[?.Dd;_!W$H$*=q$-2<$5$$!#(B $B("7oL>$K!VG[?.Dd;_!W$H5-:\$5$l$F$$$J$$>l9g$O=hM}$,9T$($^$;$s!#(B $B(">0!"Dd;_$K$O?tF|4V$[$I$*;~4V$r$$$?$@$/>l9g$,$4$6$$$^$9!#(B $B("Dd;_$^$G?tF|!"?t2s%a!<%k$,Aw?.$5$l$k$3$H$,$4$6$$$^$9$,2?B4$4N;>5$/$@$5$$!#(B ------=_NextPart_000_0018_01C78F4B.56699E30 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B;R0i$F=1B$B@l6H=1B$B$H$C$F$b#H$J7G<(HDF~8}$O%3%A%i=1B= (B=1B$B!#=1B(B
=1B$B?M:J!& = =1B$B?M$N1|$5$s$@$+$iL#$o$($kK\J*$N%U%'%m%b%s$H%;%C%/%9%F%/%K%C%/!*=1B(B<= BR>=20 =1B$BITNQ$f$(G3$(>e$,$k=3DO=3Dw$NFyM_!"
=1B$B$+$J$j%(%C%A$Jl$rL5NA$= GDs6!$7$F$$$^$9!#=1B(B
=1B$BITNQ$G$-$k?M:J$O$3$3!*=1B(B

18=1B$B:PL$K~$O$4MxMQ$G$-$^$;$s!#=1B(B
http://www.10wn.com/h/?wls


=1B$B!Z?M:J![%(%C%A$J?M:J$H=1B(B=1B$BITNQ=1B(B=1B$B$N=3DP2q$$=1B(B
=1B$B!!=1B(B
=1B$B!yC6Fa!&:J$NIb5$=1B(B
=1B$B!y4{:'
=1B$B!y%P%DM-$j$N;03Q;M3Q4X78Ey!9=1B(B

=1B$B"(FC$KM_5aITK~$N1|MM$,B?$/!"=3Dw@-$NJ}$b0B?4$7$FFb=3Do$N= =3DP2q$$$,8+$D$+$j$^$9!#=1B(B


=1B$B"($^$?L$:'$NJ}$G$b!"FyBN4X7= 8$@$1$r5a$a$kJ}$bB??tEPO?$7$F$*$j$^$9$N$G!"=1B(B
=1B$BL$:'
=1B$B"= (:#$N@83h$r0lJQ$5$;$k!"5.=3Dw$KJ{$2$k=1B(B=20 =1B$B!V=1B(BWIFE=1B$B!!=1B(BLIFE=1B$B!!=1B(BSTYLE= =1B$B!W=1B(B

18=1B$B:PL$K~$O$4MxMQ$G$-$^$;$s!#=1B(B
http://www.10wn.com/h/?wls

=1B$B!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y= !z!y!z!y!z!y!z!y!z!y!z=1B(B







=1B$B("=1B(B    =20 =1B$BG[?.Dd;_$O%3%A%i$^$G!#=1B(B
=1B$B("=1B(B     = DeliveryStop
=1B$B("=1B(B     refusal@mailmaster.dtdns.net
=1B$B("=1B(B
=1B$B("!ZG[?.Dd;_=1B$B("I,= $:7oL>$K!VG[?.Dd;_!W$H$*=3Dq$-2<$5$$!#=1B(B
=1B$B("7oL>$K!VG[?.Dd;_!W$= H5-:\$5$l$F$$$J$$>l9g$O=3DhM}$,9T$($^$;$s!#=1B(B
=1B$B(">0!"Dd;_$K$O?t= F|4V$[$I$*;~4V$r$$$?$@$/>l9g$,$4$6$$$^$9!#=1B(B
=1B$B("Dd;_$^$G?tF|!"?= t2s%a!<%k$,Aw?.$5$l$k$3$H$,$4$6$$$^$9$,2?B4$4N;>5$/$@$5$$!#=1B(B

<= /DIV> ------=_NextPart_000_0018_01C78F4B.56699E30-- From syslog-bounces@lists.ietf.org Fri May 11 07:41:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmTUa-0002w7-Kb; Fri, 11 May 2007 07:41:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmTUa-0002w2-6B for syslog@ietf.org; Fri, 11 May 2007 07:41:00 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmTUY-0003wW-Mu for syslog@ietf.org; Fri, 11 May 2007 07:41:00 -0400 Received: from pc6 (1Cust26.tnt3.lnd4.gbr.da.uu.net [62.188.132.26]) by astro.systems.pipex.net (Postfix) with SMTP id C78F3E00025B; Fri, 11 May 2007 12:40:55 +0100 (BST) Message-ID: <01c101c793b8$5bfcace0$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , References: <000b01c78e59$d3faa1c0$0601a8c0@pc6> Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol Date: Fri, 11 May 2007 12:35:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris I looked some more and am happy with it; the changes are thorough and comprehensive. I did wonder about the use of "device" which used to have a technical meaning in early versions of the I-D and now I take not to have. 'Machine' is I think used in the same sense, of the box/stack in general without any more specific meaning and that seems fine. One minor nit grabbed me, an extra comma in s.1 in " reliable, and secure syslog extensions suffer from the lack of a" where the comma is absent in the same sentence in the Abstract. I take it we are still awaiting a further -tls for review before the three of them go to the rfc-editor. Tom Petch ----- Original Message ----- From: "tom.petch" To: "Chris Lonvick" ; Sent: Friday, May 04, 2007 4:37 PM Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol > Chris > > I have looked at this and will look at it again in more depth next week. Some > of the new terminology in s.3 is unfamiliar to me and, while the end result is > not as complex as say RFC3411, it is still going to take a while for me to grasp > (by inference) the role of eg parser and formatter, the (redefined) sender and > receiver, and to work out which is responsible for which bits on the wire and > see if the usage hangs together. The changes are more extensive than I > anticipated. Probably, they much improve the precision but, at first sight, I > am less certain about the increase in clarity. > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Wednesday, May 02, 2007 10:45 PM > Subject: [Syslog] FINAL review of draft-ietf-syslog-protocol > > > > Hi Folks, > > > > David and I would like to hand off this final version to Sam for > > publication by Friday. I have performed an initial review and feel that > > the changes address the IETF Last Call items. > > > > The changes requested from the IETF Last Call were: > > > > Item 1) Severity Range - The range of the Severity is not bound. The WG > > decided that it needs to be bound in the range of 0 to 7 inclusive. > > > > Item 2) Language Tags - BCP47 (RFC 4646) is the IETF standard for language > > tags. The document needs to be compliant with this standard. Section > > 7.3.3 specifies the use of ISO 639 (which was the only reference available > > at the time we discussed languages in the mailing list.) Sam asked that > > we need to change the language tags to BCP47 to justify our decision. I've > > found no compelling reason to continue to use the ISO 639 tags. We need > > to change that paragraph to state that BCP47 language tags will be used. > > The current "MAY" in Section 7.3.3 should still be used. > > > > Item 3 - Deadlocks - There was a lengthy discussion about using a reliable > > delivery mechanism for syslog and how certain circumstances could cause > > the loss of messages. (I personally felt it was not addressing any > > normative text in the document.) A note about "deadlocks" in Section 8.5 > > has been requested by Sam. This will need to be short. > > > > Item 4 - IANA - We should review the document to see if there are any IANA > > registry values that may be revised by IETF Consensus rather than > > Standards Actions. I'll make a review and let you know if I find > > anything. > > > > Item 5 - Definitions - The definitions of "sender" "receiver" "relay", > > "originator" and "collector" need to be tightened up. They are somewhat > > inconsistent now and are required by the -device-mib document. > > > > > > You may view the differences between -19 and -20 here: > > http://tools.ietf.org/wg/syslog/ > > Click on "draft-ietf-syslog-protocol" and select your method of seeing the > > diffs from -19. > > > > Please submit any comments you have to the WG that concern how Rainer > > addressed these issues in this document. > > > > Thanks, > > Chris > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri May 11 09:34:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVGp-0001iQ-Uf; Fri, 11 May 2007 09:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVGp-0001iE-6D for syslog@ietf.org; Fri, 11 May 2007 09:34:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmVGo-0002MM-Id for syslog@ietf.org; Fri, 11 May 2007 09:34:55 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 11 May 2007 06:34:54 -0700 X-IronPort-AV: i="4.14,523,1170662400"; d="scan'208"; a="421017161:sNHT48423472" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4BDYsOd008886; Fri, 11 May 2007 06:34:54 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4BDYr07002114; Fri, 11 May 2007 13:34:53 GMT Date: Fri, 11 May 2007 06:34:53 -0700 (PDT) From: Chris Lonvick To: "tom.petch" Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol In-Reply-To: <01c101c793b8$5bfcace0$0601a8c0@pc6> Message-ID: References: <000b01c78e59$d3faa1c0$0601a8c0@pc6> <01c101c793b8$5bfcace0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5712; t=1178890494; x=1179754494; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20FINAL=20review=20of=20draft-ietf-syslog-pr otocol |Sender:=20; bh=WFlgEM+QFSQZpLCIZH+fk2SKO00plLUqfsG7MdsXBxM=; b=Aak//5nQp+DM1bbu6DnOZuiba9/jDHiYEy+u7MbTg7swwEAWmp0n9QjyJgJ9tqv3wNeufUmW dFIjOdrFpmQhF6/QPonU/+p3YddCzn7UURwMsrKpfvoMIE+VMVIypn2z; Authentication-Results: sj-dkim-6; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Tom, The credit goes to Rainer who put in the time and effort. :-) I have found these minor nits as well: === A.2 Implementers should note the message size limitations outlined in Section 6.1 and try to keep the most important data early in the message (within the minimum guaranteed length). This ensures the data will be seen by the collector or relay even if the receiver at a relay on the message path truncates the message. ...even if the reciever _as_ a relay on the message path... s/confusability/confusion/ s/dcument/document/g === These can be corrected in AUTH48. draft-ietf-syslog-protocol and draft-ietf-transport-tls are back in Sam's hands. I expect an upcoming telechat will move them forward. They don't need to wait for transport-tls to be sent to the RFC Editor, but the RFC Editor won't publish them until all normative references are in good standing. I have the latest draft-ietf-syslog-transport-tls and just finished my review of it last night. I believe that it addresses all of Sam's concerns. I'm going to ask Miao and Yuzhi to submit it to the ID editor so we can review in the WG. I appreciate your review. Thanks, Chris On Fri, 11 May 2007, tom.petch wrote: > Chris > > I looked some more and am happy with it; the changes are thorough and > comprehensive. I did wonder about the use of "device" which used to have a > technical meaning in early versions of the I-D and now I take not to have. > 'Machine' is I think used in the same sense, of the box/stack in general without > any more specific meaning and that seems fine. > > One minor nit grabbed me, an extra comma in s.1 in > " reliable, and secure syslog extensions suffer from the lack of a" > where the comma is absent in the same sentence in the Abstract. > > I take it we are still awaiting a further -tls for review before the three of > them go to the rfc-editor. > > Tom Petch > > ----- Original Message ----- > From: "tom.petch" > To: "Chris Lonvick" ; > Sent: Friday, May 04, 2007 4:37 PM > Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol > > >> Chris >> >> I have looked at this and will look at it again in more depth next week. Some >> of the new terminology in s.3 is unfamiliar to me and, while the end result > is >> not as complex as say RFC3411, it is still going to take a while for me to > grasp >> (by inference) the role of eg parser and formatter, the (redefined) sender and >> receiver, and to work out which is responsible for which bits on the wire and >> see if the usage hangs together. The changes are more extensive than I >> anticipated. Probably, they much improve the precision but, at first sight, I >> am less certain about the increase in clarity. >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Chris Lonvick" >> To: >> Sent: Wednesday, May 02, 2007 10:45 PM >> Subject: [Syslog] FINAL review of draft-ietf-syslog-protocol >> >> >>> Hi Folks, >>> >>> David and I would like to hand off this final version to Sam for >>> publication by Friday. I have performed an initial review and feel that >>> the changes address the IETF Last Call items. >>> >>> The changes requested from the IETF Last Call were: >>> >>> Item 1) Severity Range - The range of the Severity is not bound. The WG >>> decided that it needs to be bound in the range of 0 to 7 inclusive. >>> >>> Item 2) Language Tags - BCP47 (RFC 4646) is the IETF standard for language >>> tags. The document needs to be compliant with this standard. Section >>> 7.3.3 specifies the use of ISO 639 (which was the only reference available >>> at the time we discussed languages in the mailing list.) Sam asked that >>> we need to change the language tags to BCP47 to justify our decision. I've >>> found no compelling reason to continue to use the ISO 639 tags. We need >>> to change that paragraph to state that BCP47 language tags will be used. >>> The current "MAY" in Section 7.3.3 should still be used. >>> >>> Item 3 - Deadlocks - There was a lengthy discussion about using a reliable >>> delivery mechanism for syslog and how certain circumstances could cause >>> the loss of messages. (I personally felt it was not addressing any >>> normative text in the document.) A note about "deadlocks" in Section 8.5 >>> has been requested by Sam. This will need to be short. >>> >>> Item 4 - IANA - We should review the document to see if there are any IANA >>> registry values that may be revised by IETF Consensus rather than >>> Standards Actions. I'll make a review and let you know if I find >>> anything. >>> >>> Item 5 - Definitions - The definitions of "sender" "receiver" "relay", >>> "originator" and "collector" need to be tightened up. They are somewhat >>> inconsistent now and are required by the -device-mib document. >>> >>> >>> You may view the differences between -19 and -20 here: >>> http://tools.ietf.org/wg/syslog/ >>> Click on "draft-ietf-syslog-protocol" and select your method of seeing the >>> diffs from -19. >>> >>> Please submit any comments you have to the WG that concern how Rainer >>> addressed these issues in this document. >>> >>> Thanks, >>> Chris >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri May 11 09:54:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVZ7-0005p6-Cq; Fri, 11 May 2007 09:53:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVZ5-0005lS-Qf for syslog@ietf.org; Fri, 11 May 2007 09:53:47 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmVZ5-0004jh-CM for syslog@ietf.org; Fri, 11 May 2007 09:53:47 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070511135346b1200f7mdke>; Fri, 11 May 2007 13:53:46 +0000 From: "David Harrington" To: "'Chris Lonvick'" , "'tom.petch'" References: <000b01c78e59$d3faa1c0$0601a8c0@pc6><01c101c793b8$5bfcace0$0601a8c0@pc6> Subject: RE: [Syslog] FINAL review of draft-ietf-syslog-protocol Date: Fri, 11 May 2007 09:53:40 -0400 Message-ID: <045101c793d3$c8595a30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceT0SpFZZFTq8hVQdW1fTXrILyNNQAAZtEQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I think Chris meant to say "draft-ietf-syslog-protocol and draft-ietf-transport-udp are back in Sam's hands. draft-ietf-transport-tls only requires a WG review before going back to Sam. We are waiting for an updated -sign- so we can start the WGLC. Wliot published an updated 3195bis that needs WG review before we can do anything with it. MIB still needs work. Based on comments received, I am not convinced it represents WG consensus, and it needs some MIB technical fixes. Hopefully we will make some progress this month, but I'd rather see us complete the other work first, since that is closer to done. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, May 11, 2007 9:35 AM > To: tom.petch > Cc: syslog@ietf.org > Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol > > Hi Tom, > > The credit goes to Rainer who put in the time and effort. :-) > > I have found these minor nits as well: > === > A.2 > Implementers should note the message size limitations outlined in > Section 6.1 and try to keep the most important data early in the > message (within the minimum guaranteed length). This ensures the > data will be seen by the collector or relay even if the > receiver at a > relay on the message path truncates the message. > > ...even if the reciever _as_ a relay on the message path... > > s/confusability/confusion/ > > s/dcument/document/g > === > These can be corrected in AUTH48. > > draft-ietf-syslog-protocol and draft-ietf-transport-tls are > back in Sam's > hands. I expect an upcoming telechat will move them forward. > They don't > need to wait for transport-tls to be sent to the RFC Editor, > but the RFC > Editor won't publish them until all normative references are in good > standing. > > I have the latest draft-ietf-syslog-transport-tls and just > finished my > review of it last night. I believe that it addresses all of Sam's > concerns. I'm going to ask Miao and Yuzhi to submit it to > the ID editor > so we can review in the WG. > > I appreciate your review. > Thanks, > Chris > > > On Fri, 11 May 2007, tom.petch wrote: > > > Chris > > > > I looked some more and am happy with it; the changes are > thorough and > > comprehensive. I did wonder about the use of "device" > which used to have a > > technical meaning in early versions of the I-D and now I > take not to have. > > 'Machine' is I think used in the same sense, of the > box/stack in general without > > any more specific meaning and that seems fine. > > > > One minor nit grabbed me, an extra comma in s.1 in > > " reliable, and secure syslog extensions suffer from the > lack of a" > > where the comma is absent in the same sentence in the Abstract. > > > > I take it we are still awaiting a further -tls for review > before the three of > > them go to the rfc-editor. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "tom.petch" > > To: "Chris Lonvick" ; > > Sent: Friday, May 04, 2007 4:37 PM > > Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol > > > > > >> Chris > >> > >> I have looked at this and will look at it again in more > depth next week. Some > >> of the new terminology in s.3 is unfamiliar to me and, > while the end result > > is > >> not as complex as say RFC3411, it is still going to take a > while for me to > > grasp > >> (by inference) the role of eg parser and formatter, the > (redefined) sender and > >> receiver, and to work out which is responsible for which > bits on the wire and > >> see if the usage hangs together. The changes are more > extensive than I > >> anticipated. Probably, they much improve the precision > but, at first sight, I > >> am less certain about the increase in clarity. > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "Chris Lonvick" > >> To: > >> Sent: Wednesday, May 02, 2007 10:45 PM > >> Subject: [Syslog] FINAL review of draft-ietf-syslog-protocol > >> > >> > >>> Hi Folks, > >>> > >>> David and I would like to hand off this final version to Sam for > >>> publication by Friday. I have performed an initial > review and feel that > >>> the changes address the IETF Last Call items. > >>> > >>> The changes requested from the IETF Last Call were: > >>> > >>> Item 1) Severity Range - The range of the Severity is not > bound. The WG > >>> decided that it needs to be bound in the range of 0 to 7 > inclusive. > >>> > >>> Item 2) Language Tags - BCP47 (RFC 4646) is the IETF > standard for language > >>> tags. The document needs to be compliant with this > standard. Section > >>> 7.3.3 specifies the use of ISO 639 (which was the only > reference available > >>> at the time we discussed languages in the mailing list.) > Sam asked that > >>> we need to change the language tags to BCP47 to justify > our decision. I've > >>> found no compelling reason to continue to use the ISO 639 > tags. We need > >>> to change that paragraph to state that BCP47 language > tags will be used. > >>> The current "MAY" in Section 7.3.3 should still be used. > >>> > >>> Item 3 - Deadlocks - There was a lengthy discussion about > using a reliable > >>> delivery mechanism for syslog and how certain > circumstances could cause > >>> the loss of messages. (I personally felt it was not > addressing any > >>> normative text in the document.) A note about > "deadlocks" in Section 8.5 > >>> has been requested by Sam. This will need to be short. > >>> > >>> Item 4 - IANA - We should review the document to see if > there are any IANA > >>> registry values that may be revised by IETF Consensus rather than > >>> Standards Actions. I'll make a review and let you know if I find > >>> anything. > >>> > >>> Item 5 - Definitions - The definitions of "sender" > "receiver" "relay", > >>> "originator" and "collector" need to be tightened up. > They are somewhat > >>> inconsistent now and are required by the -device-mib document. > >>> > >>> > >>> You may view the differences between -19 and -20 here: > >>> http://tools.ietf.org/wg/syslog/ > >>> Click on "draft-ietf-syslog-protocol" and select your > method of seeing the > >>> diffs from -19. > >>> > >>> Please submit any comments you have to the WG that > concern how Rainer > >>> addressed these issues in this document. > >>> > >>> Thanks, > >>> Chris > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri May 11 09:57:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVcv-00075s-31; Fri, 11 May 2007 09:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVct-00075n-NO for syslog@ietf.org; Fri, 11 May 2007 09:57:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmVcs-000579-FQ for syslog@ietf.org; Fri, 11 May 2007 09:57:43 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 11 May 2007 06:57:42 -0700 X-IronPort-AV: i="4.14,523,1170662400"; d="scan'208"; a="421027425:sNHT38540976" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4BDvf9l017128; Fri, 11 May 2007 06:57:41 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4BDvf07010850; Fri, 11 May 2007 13:57:41 GMT Date: Fri, 11 May 2007 06:57:41 -0700 (PDT) From: Chris Lonvick To: David Harrington Subject: RE: [Syslog] FINAL review of draft-ietf-syslog-protocol In-Reply-To: <045101c793d3$c8595a30$0600a8c0@china.huawei.com> Message-ID: References: <000b01c78e59$d3faa1c0$0601a8c0@pc6><01c101c793b8$5bfcace0$0601a8c0@pc6> <045101c793d3$c8595a30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=295; t=1178891861; x=1179755861; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20[Syslog]=20FINAL=20review=20of=20draft-ietf-syslog-pr otocol |Sender:=20; bh=SWGvD2ghPPWn34XJUR4+oewGp1E+PRGj6JVo6aGqzCQ=; b=F/jQ4MPCp1Rjyon9pmtKzRpMooZUqBs6nSqJVtFAjPPz1dCLDRk5hgSAOBKSdA1VyhlrgAv4 oKxU7IONiFtksWJRzv8LoPkzXOCayMbDoHhDNTqAWHl1XOK8aVGFTNqh; Authentication-Results: sj-dkim-7; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, On Fri, 11 May 2007, David Harrington wrote: > Hi, > > I think Chris meant to say "draft-ietf-syslog-protocol and > draft-ietf-transport-udp are back in Sam's hands. > draft-ietf-transport-tls only requires a WG review before going back > to Sam. Doh! Yup. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun May 13 21:16:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnPAR-0002QA-32; Sun, 13 May 2007 21:16:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnPAP-0002N5-3C for syslog@ietf.org; Sun, 13 May 2007 21:16:01 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnPAN-0002KH-Qu for syslog@ietf.org; Sun, 13 May 2007 21:16:01 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AAB4E400F; Sun, 13 May 2007 21:15:58 -0400 (EDT) To: syslog@ietf.org From: Sam Hartman Message-Id: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> Date: Sun, 13 May 2007 21:15:58 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: hartmans-ietf@mit.edu Subject: [Syslog] Comments on draft-ietf-syslog-protocol-20 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi. Thanks for the new draft. There are a lot of changes in this version; it will definitely require a new ietf last call. I'd recommend that the WG evaluate the changes and ask whether at this stage in the process they are actually required. Perhaps they are. 1) You cannot use originator and sender in the same layering diagram if they are going to mean different things. May I suggest calling the entity a transport sender/transport receiver. 2) I question whether all three of sender/originator/formatter are needed. I recommend dropping formatter and perser, folding their behavior in somewhere else. You are misusing the terms (as an example, the following diff suggests that we care about the formatter's IP addresses not the originator's). I can believe that the formatter chooses the IP address, but I don't think it should choose one of its addresses if it is on a different machine than the originator. Misuse of terms from those defining the terms suggests that you have too many terms. + Formatters SHOULD consistently use the same value in the HOSTNAME + field for as long as possible. If the formatter uses IP addresses + inside hostname, the following rules apply: If the formatter is + multihomed, this value SHOULD be one of its actual IP addresses. If + a formatter is running on a machine that has both statically and + dynamically assigned addresses, then that value SHOULD be from the + statically assigned addresses. As an alternative, the formatter MAY + use the IP address of the interface that is used to send the message. If you keep formatter and parser, please for each use of originator, formatter, parser and collector explain why that is the correct term. 3) Why does this obselete 3164? That document describes a ifferent protocol. 4) Why was a.8 removed? _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon May 14 08:33:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZjZ-0005H6-OO; Mon, 14 May 2007 08:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZjY-0005Gw-IW for syslog@ietf.org; Mon, 14 May 2007 08:33:00 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZjW-0001bu-5M for syslog@ietf.org; Mon, 14 May 2007 08:33:00 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070514123257b1200f7dole>; Mon, 14 May 2007 12:32:57 +0000 From: "David Harrington" To: "'Sam Hartman'" , References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> Subject: RE: [Syslog] Comments on draft-ietf-syslog-protocol-20 Date: Mon, 14 May 2007 08:32:49 -0400 Message-ID: <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceVxXNeHz7FuCUCSESeHNcXuegc7wAVmTmQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I agree with Sam that the WG should review the large changes made since IETF last call. I'll respond to these questions -- as a contributor. Let me start out by stating that I have no previous experience with syslog before becoming co-chair. My background has been SNMP-based NMS development. I came in as co-chair primarily to help get the documents finished and through the process, because the WG had stalled and Chris didn't have the time to spend on getting the WG through the process alone. my commnts inline. > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Sunday, May 13, 2007 9:16 PM > To: syslog@ietf.org > Cc: hartmans-ietf@mit.edu > Subject: [Syslog] Comments on draft-ietf-syslog-protocol-20 > > > > Hi. Thanks for the new draft. > > There are a lot of changes in this version; it will definitely require > a new ietf last call. I'd recommend that the WG evaluate the changes > and ask whether at this stage in the process they are actually > required. Perhaps they are. > If we are developing a standard, the documents should describe how the system works well enough for those with no previous experience in the protocol to be able to understand it from the documents. I have always used the rule "IETF documents should be clear and unambiguous" as various roles as chair and editor in the IETF. I found that protocol-17 failed that test. This became quite apparent when there were debates about terminology related to the -tls- draft and the -mib- draft. > > 1) You cannot use originator and sender in the same layering > diagram if they are going to mean different things. May I > suggest calling the entity a transport sender/transport receiver. > > 2) I question whether all three of sender/originator/formatter are > needed. I recommend dropping formatter and perser, folding their > behavior in somewhere else. As we tried to work on the docuemnts, especially the mib, it became clear that different people have different ideas of what each term means. In the mib it is necessary to model the abstract concepts of how the system works. The concepts of syslog seem to be that some entity, e.g. a device, request that a syslog message be created and logged/sent on its behalf. Implementation designs vary widely depending on a lot of factors, but all seem to accept that some process-or-whatever has an event occur that should be looged/sent and that some process-or-whatever creates a message, and some process-or-whatever sends the prepared message. Since the WG has been able to separate the protocl form the transport mappings, the process-or-whatever that craetes the message and th eprocess-or-whatever that sends the message are separate abstract concepts. Why is this important? because the mib contains counters for things like number-of-messages-sent; which portion of the system actually knows how many messages were sent? The requesting process-or-whatever knows ho wmany were requested; the message-formatting process-or-whatever knows ho wmessages were prepared for sending, but the transport sender is the only one that knows how many managed to get through all the intermediate error-checking and were actually sent. Only the transport-sender process has the information to make available to the mib. If different implementations count this counter from different points in the process, the results will not be interoperable - an NMS will not be able to accurately compare the values from two syslog daemons/processes/applications and be able to compare apples-to-apples rather than comparing apples-to-oranges. > > You are misusing the terms (as an example, the following diff suggests > that we care about the formatter's IP addresses not the originator's). > I can believe that the formatter chooses the IP address, but I don't > think it should choose one of its addresses if it is on a different > machine than the originator. Misuse of terms from those defining the > terms suggests that you have too many terms. >From the managed node perspective, it might make perfect sense to use the originator's IP address sometimes and the formatter's address sometimes, but from the point of an operator or NMS, it can make all the difference in the world what that value means vis-a-vis the network. We need consistency across implementations. If that value will be used for security purposes, I think it is even more important that it be consistent about what it represents. Maybe there should be two different places to represent IP address if it means two different things. Again, the terminology has been tremendously unclear and ambiguous. This WG should make the concepts and terminology clear and unambiguous. > > + Formatters SHOULD consistently use the same value in the HOSTNAME > + field for as long as possible. If the formatter uses IP addresses > + inside hostname, the following rules apply: If the formatter is > + multihomed, this value SHOULD be one of its actual IP > addresses. If > + a formatter is running on a machine that has both statically and > + dynamically assigned addresses, then that value SHOULD be from the > + statically assigned addresses. As an alternative, the > formatter MAY > + use the IP address of the interface that is used to send > the message. > > > If you keep formatter and parser, please for each use of originator, > formatter, parser and collector explain why that is the correct term. Apparently, we still have not gotten the abstract concepts and the terminology to be clear and unambiguous, since you could not understand it. > > > 3) Why does this obselete 3164? That document describes a ifferent > protocol. RFC3164 describes a variety of implementations, and during our work, we found that those descriptions only captured the tip of the iceberg. As a result, that informational document is inaccurate and misleading, and should be considered obsolete. We don't declare the implementations described obsolete, or the non-IETF defacto standard to be obsolete; we declare the informational RFC to be obsolete. Historic could also work, if the IESG prefers that choice. . > > > 4) Why was a.8 removed? a.8 and the section on PROCID used lots of words, but at the end of going through all those words, what was said was pretty straightforward - there was no agreement on the syntax or meaning of PROCID. The only agreement appeared to be that if the value changed, that was significant, and some implementations used these fields in a similar way. We summarized the discussion from a.8 (in -17-) and added it to 6.2.6 (in -20-). David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon May 14 16:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngaN-00028f-Vq; Mon, 14 May 2007 15:52:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngYz-0007Ng-0X; Mon, 14 May 2007 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HngYy-0004Jf-Jl; Mon, 14 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 87552175F8; Mon, 14 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HngYU-0006T4-8t; Mon, 14 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 14 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-10.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : TLS Transport Mapping for Syslog Author(s) : F. Miao, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-10.txt Pages : 12 Date : 2007-5-14 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-tls-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-tls-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-14131946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-14131946.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Wed May 16 10:00:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoK3e-0005h5-T5; Wed, 16 May 2007 10:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoK3d-0005gs-Jf for syslog@ietf.org; Wed, 16 May 2007 10:00:49 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoK3c-0002bp-Dn for syslog@ietf.org; Wed, 16 May 2007 10:00:49 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CF625400F; Wed, 16 May 2007 10:00:46 -0400 (EDT) From: Sam Hartman To: syslog@ietf.org Date: Wed, 16 May 2007 10:00:46 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Syslog] Obseleting 3164 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I talked to David on the phone and he explained why the WG has chosen to obselete 3164. His explanation made sense to me so I am no longer concerned about that. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From necojp@citiz.net Fri May 18 07:52:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp10T-0000yO-M1 for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Fri, 18 May 2007 07:52:25 -0400 Received: from [222.171.206.194] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp10Q-00058q-Kr for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Fri, 18 May 2007 07:52:25 -0400 Received: from qrrodbx8 (unknown [211.224.37.229]) by smtp31 (Coremail) with SMTP id 5bjxHYgnNAjLn7mz.1 for ; Sun, 09 May 2004 09:21:48 +0800 (CST) X-Originating-IP: [211.224.37.229] Subject: =?iso-2022-jp?B?GyRCSWI1JCEmSVROUT1pPzQ8VCROSn0kWCFWQGRCUCRLJVAbKEI=?= From: =?shift-jis?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 2.4 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab $B@$$NCf$N=w@-$N#5#8!s$,ITNQ$r$7$F$$$k$H$$$&6C$-$ND4::7k2L!*(B http://www.aaqw.net/h/?wls $B$J$N$K!"$J$<<+J,$@$1$K!VG[?.Dd;_!W$H$*=q$-2<$5$$!#(B $B("7oL>$K!VG[?.Dd;_!W$H5-:\$5$l$F$$$J$$>l9g$O=hM}$,9T$($^$;$s!#(B $B(">0!"Dd;_$K$O?tF|4V$[$I$*;~4V$r$$$?$@$/>l9g$,$4$6$$$^$9!#(B $B("Dd;_$^$G?tF|!"?t2s%a!<%k$,Aw?.$5$l$k$3$H$,$4$6$$$^$9$,!"(B $B("2?B4$4N;>5$/$@$5$$!#(B $B(&(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B From syslog-bounces@lists.ietf.org Fri May 18 11:53:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4lj-000736-Sb; Fri, 18 May 2007 11:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4li-00072y-RW for syslog@lists.ietf.org; Fri, 18 May 2007 11:53:26 -0400 Received: from ns1.berkelyx.com ([204.15.39.10] helo=fresnel.adequest.lan) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp4lh-0002K7-DG for syslog@lists.ietf.org; Fri, 18 May 2007 11:53:26 -0400 Received: from pavilion (firelite.adequest.lan [192.168.1.100]) by fresnel.adequest.lan (8.13.4/8.13.4) with SMTP id l4IFs6lK047469 for ; Fri, 18 May 2007 11:54:06 -0400 (EDT) (envelope-from aiaa@adequest.ca) Message-ID: <00f701c79964$d657b500$6401a8c0@pavilion> From: "Mike Adewole" To: Date: Fri, 18 May 2007 11:54:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Status: No, score=-2.8 required=3.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on fresnel.adequest.lan X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Syslog] Comments on syslog-protocol-20 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hello everyone, I'm in the process of writing a new syslog server and thought it'd be cool to make it comply with the latest and greatest syslog rfc. But after reading draft-ietf-syslog-protocol-20 (DISP20), I have a number of concerns: (a) Section 5.1. I don't quite see how a "non-disruptive transition" can be achieved by requiring new implementations to support udp and tls transports. I have no use for the udp transport because transport level reliability is a prerequisite for my project. People writing a local syslog server that will only be deployed on their lan will probably not see any value in the tls transport either. If at all possible, please change the language in this section to SHOULD instead of MUST. There are other ways to achieve a non-disruptive transition [see point (c) below]. (b) Section 6. I don't understand why PRIVAL in the ABNF is restricted to 0..191, especially since section 6.2.1 claims that PRIVAL as described in that section is not normative. How about simply saying that PRIVAL may have any value and moving Tables 1 & 2 to an appendix titled "Recommended PRIVALs for Unix-like Platforms" or something similar ? As it stands, it looks too much like syslog is being designed for Unix-like platforms only. (c) Section 6.2.1. I have issues with the requirement that PRIVAL MUST start with "<", end with ">" and not have more than 3 decimal digits. The problem is that this makes it very hard to detect if any given message should be parsed according to DISP20 or according to common usage (RFC3164). If you do the exact opposite by requiring PRIVAL to satisfy one or more of the following: (i) starts with any token other than "<" (choose for example, "" (choose for example, "->") (iii) has a minimum of four decimal digits then by simply looking at PRIVAL, the message receiver can decide whether the message is from a DISP20 compliant source and should be parsed accordingly. This also facilitates a non-disruptive transition to the new syslog protocol. Cheers, Mike _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri May 18 13:08:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5w8-0001ae-1v; Fri, 18 May 2007 13:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5w7-0001aZ-9q for syslog@ietf.org; Fri, 18 May 2007 13:08:15 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp5w6-00056i-LV for syslog@ietf.org; Fri, 18 May 2007 13:08:15 -0400 Received: from pc6 (1Cust104.tnt16.lnd4.gbr.da.uu.net [62.188.145.104]) by galaxy.systems.pipex.net (Postfix) with SMTP id 38358E000705; Fri, 18 May 2007 18:08:11 +0100 (BST) Message-ID: <028e01c79966$3719cc60$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Sam Hartman'" , "syslog" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> Subject: Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 Date: Fri, 18 May 2007 17:53:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Not sure where this draft is heading, but as a WG member, comments Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Sam Hartman'" ; Sent: Monday, May 14, 2007 2:32 PM Subject: RE: [Syslog] Comments on draft-ietf-syslog-protocol-20 > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Sunday, May 13, 2007 9:16 PM > > To: syslog@ietf.org > > Cc: hartmans-ietf@mit.edu > > Subject: [Syslog] Comments on draft-ietf-syslog-protocol-20 > > > > > > There are a lot of changes in this version; it will definitely > require > > a new ietf last call. I'd recommend that the WG evaluate the > changes > > and ask whether at this stage in the process they are actually > > required. Perhaps they are. > > > > If we are developing a standard, the documents should describe how the > system works well enough for those with no previous experience in the > protocol to be able to understand it from the documents. I have always > used the rule "IETF documents should be clear and unambiguous" as > various roles as chair and editor in the IETF. > > I found that protocol-17 failed that test. This became quite apparent > when there were debates about terminology related to the -tls- draft > and the -mib- draft. > > > > > 1) You cannot use originator and sender in the same layering > > diagram if they are going to mean different things. May I > > suggest calling the entity a transport sender/transport receiver. > > I do not understand this comment. Whilst in lay English, originator and sender might be synonyms, I see them here redefined as functions in layers application and transport respectively, which, while perhaps not what I would do, seems ok. Qualifying sender and receiver with transport is also ok with me. > > 2) I question whether all three of sender/originator/formatter are > > needed. I recommend dropping formatter and perser, folding their > > behavior in somewhere else. > > As we tried to work on the docuemnts, especially the mib, it became > clear that different people have different ideas of what each term > means. In the mib it is necessary to model the abstract concepts of > how the system works. > > The concepts of syslog seem to be that some entity, e.g. a device, > request that a syslog message be created and logged/sent on its > behalf. Implementation designs vary widely depending on a lot of > factors, but all seem to accept that some process-or-whatever has an > event occur that should be looged/sent and that some > process-or-whatever creates a message, and some process-or-whatever > sends the prepared message. > > Since the WG has been able to separate the protocl form the transport > mappings, the process-or-whatever that craetes the message and th > eprocess-or-whatever that sends the message are separate abstract > concepts. > > Why is this important? because the mib contains counters for things > like number-of-messages-sent; which portion of the system actually > knows how many messages were sent? The requesting process-or-whatever > knows ho wmany were requested; the message-formatting > process-or-whatever knows ho wmessages were prepared for sending, but > the transport sender is the only one that knows how many managed to > get through all the intermediate error-checking and were actually > sent. Only the transport-sender process has the information to make > available to the mib. If different implementations count this counter > from different points in the process, the results will not be > interoperable - an NMS will not be able to accurately compare the > values from two syslog daemons/processes/applications and be able to > compare apples-to-apples rather than comparing apples-to-oranges. I am with Sam on this. Reading -syslog-protocol, I reverse engineered what formatter and parser meant and yes, there are used in a specific and consistent sense, but I did not think that they improved clarity or understanding of syslog-protocol. I agree where syslog daemons are built in this manner, then this concept would allow a finer grained MIB module but I am not sure that the gain in precision justifies the gain in complexity and would see it as adequate to have formatter and parser folded into the layer above. > > > > You are misusing the terms (as an example, the following diff > suggests > > that we care about the formatter's IP addresses not the > originator's). > > I can believe that the formatter chooses the IP address, but I don't > > think it should choose one of its addresses if it is on a different > > machine than the originator. Misuse of terms from those defining > the > > terms suggests that you have too many terms. > > >From the managed node perspective, it might make perfect sense to use > the originator's IP address sometimes and the formatter's address > sometimes, but from the point of an operator or NMS, it can make all > the difference in the world what that value means vis-a-vis the > network. We need consistency across implementations. > > If that value will be used for security purposes, I think it is even > more important that it be consistent about what it represents. Maybe > there should be two different places to represent IP address if it > means two different things. > > Again, the terminology has been tremendously unclear and ambiguous. > This WG should make the concepts and terminology clear and > unambiguous. > > > > > + Formatters SHOULD consistently use the same value in the > HOSTNAME > > + field for as long as possible. If the formatter uses IP > addresses > > + inside hostname, the following rules apply: If the formatter is > > + multihomed, this value SHOULD be one of its actual IP > > addresses. If > > + a formatter is running on a machine that has both statically and > > + dynamically assigned addresses, then that value SHOULD be from > the > > + statically assigned addresses. As an alternative, the > > formatter MAY > > + use the IP address of the interface that is used to send > > the message. > > > > > > If you keep formatter and parser, please for each use of originator, > > formatter, parser and collector explain why that is the correct > term. > > Apparently, we still have not gotten the abstract concepts and the > terminology to be clear and unambiguous, since you could not > understand it. > > This is the sort of paragraph I reverse engineered in order to work out what a formatter and parser was but the HOSTNAME that I care about is where the syslog message started, not where it got formattered should that be on a different stack with a different HOSTNAME, so again, I am happy to see formatter and parser go. > > > > 3) Why does this obselete 3164? That document describes a ifferent > > protocol. > > RFC3164 describes a variety of implementations, and during our work, > we found that those descriptions only captured the tip of the iceberg. > As a result, that informational document is inaccurate and misleading, > and should be considered obsolete. We don't declare the > implementations described obsolete, or the non-IETF defacto standard > to be obsolete; we declare the informational RFC to be obsolete. > Historic could also work, if the IESG prefers that choice. > point now resolved I understand > . > > > > > > 4) Why was a.8 removed? > > a.8 and the section on PROCID used lots of words, but at the end of > going through all those words, what was said was pretty > straightforward - there was no agreement on the syntax or meaning of > PROCID. The only agreement appeared to be that if the value changed, > that was significant, and some implementations used these fields in a > similar way. We summarized the discussion from a.8 (in -17-) and added > it to 6.2.6 (in -20-). > No particular thoughts either way. > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From reina789@eyou.com Sat May 19 08:10:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpNlR-00010l-RR for syslog-archive@lists.ietf.org; Sat, 19 May 2007 08:10:25 -0400 Received: from [60.219.161.3] (helo=SPKxx) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpNlO-0006JC-UT for syslog-archive@lists.ietf.org; Sat, 19 May 2007 08:10:25 -0400 Received: by SPKxx (Postfix, from userid 48) id 1849C35D0D2; Sat, 19 May 2007 16:54:48 +0800 (CST) To: syslog-archive@lists.ietf.org Subject: =?ISO-2022-JP?B?GyRCQ084NSROJSolUCU1JXMkckp6JC0kPyQkJEckOSQrISklbCVZGyhC?= =?ISO-2022-JP?B?GyRCJWskT0RjJCQkRyQ5JCwzTjxCJEtKeiQxJF4kOSRoGyhCISE=?= From: Resent-Sender: reina789@eyou.com Message-ID: <20070519165448.23037@eyou.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Resent-Message-Id: <20070519093658.1849C35D0D2@SPKxx> Resent-Date: Sat, 19 May 2007 16:54:48 +0800 (CST) Resent-From: reina789@eyou.com (Apache) X-Spam-Score: 3.4 (+++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 **************************************************** $BEv%5%$%H$O(B40$BBe!A(B50$BBe$NFyBN4X78$r5a$a$F$$$k?M:J!&=O=w(B $B$,=8$^$kF|K\:GBg$NITNQ%3%_%e%K%F%#!<%5%$%H$G$9!#(B **************************************************** $B!T$4MxMQ$K4X$7$F$N$4Cm0U!U(B------------------------------- $B-5!!$4MxMQ$OCK=w6&$KITNQ$r4uK>$5$l$kJ}$N$_$H$5$;$FD:$-$^$9!#(B $B-6!!CK=w6&$K$*Aj$NCO0h!&%a!<%k%"%I%l%9!&%Q%9%o!<%I$r@_Dj$7$FD:$-$^$9!#(B $B-6!!$9$k$*Aj%"%I%l%9$,I=<($5$l$F$*$j$^$9$N$G$=$N;~E@$GD>@\$4O"Mm$r(B $B!!!!$7$FD:$$$F$b7k9=$G$9$7!"%5%$%HFb$+$i%a!<%k$K$FO"Mm$rD$7$F2<$5$$!#(B $B!ZCm0U![<+8J(BPR$BFb$KO"Mm@h$NI=<($,L5$$?M:J$5$s$O(B $B!!!!!!!!8r>D$,@.N)$7FyBN4X78Cf$G$9$N$GO"Mm@h$NI=<($,(B $B!!!!!!!!I|3h8e!":FEY8r>D$r$*4j$$CW$7$^$9!#(B ************************************************************** $B!|K\F|!"40A4L5NA$G=O$l$??M:J$HFyBN4X78$r4uK>$5$l$kCK@-$O(B $B!!(Bhttp://cjbjj.com:112/ddd/hito-41/ $B!|K\F|!"40A4L5NA$G2P>H$C$?BN$rK~$?$7$FM_$7$$=w@-$O(B $B!!(Bhttp://cjbjj.com:112/ddd/hito-41/ ************************************************************** $B!zBT9g$o$;$N>l=j$r%j%"%k%?%$%`$G$d$j Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqY4G-0003T7-Ch; Tue, 22 May 2007 13:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqY4G-0003Sz-1V for syslog@ietf.org; Tue, 22 May 2007 13:22:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqY4F-0005tA-K4 for syslog@ietf.org; Tue, 22 May 2007 13:22:40 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 22 May 2007 10:22:39 -0700 X-IronPort-AV: i="4.14,566,1170662400"; d="scan'208"; a="156203547:sNHT46198071" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4MHMd72018308; Tue, 22 May 2007 10:22:39 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4MHMb07019101; Tue, 22 May 2007 17:22:38 GMT Date: Tue, 22 May 2007 10:22:37 -0700 (PDT) From: Chris Lonvick To: "tom.petch" Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 In-Reply-To: <028e01c79966$3719cc60$0601a8c0@pc6> Message-ID: References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4754; t=1179854559; x=1180718559; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Layer=20diagram=20&=20mib=20counters=20-=20was=3ARe=3A=20[Sys log]=20Comments=20on=0A=20draft-ietf-syslog-protocol-20 |Sender:=20; bh=Hw0rhOgCalfHPUUwh7/pAQ9NtrcITvwcMd2TQCladRw=; b=ihS7tA2pEA8W55bdHyW2iXDZL4Zyk35wXgbl+jqjYWs21WNbMeCMl/HbxtJiE08cpAMu2UFi nDB3m1eKecEAoXdVmx2BiUd46X6tAojm6kO4dIKz5eRv2dyss7bp5+Yf; Authentication-Results: sj-dkim-8; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 'Sam Hartman' , syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi All, What I'm seeing is that our effort to add granularity for mib accounting has made the document less clear. My apologies for that. Does the following make more sense: +---------------------+ +---------------------+ | content | | content | |---------------------| |---------------------| | syslog application | | syslog application | (originator, | | | | collector, relay) |---------------------| |---------------------| | syslog transport | | syslog transport | (transport sender, | | | | (transport receiver) +---------------------+ +---------------------+ ^ ^ | | -------------------------- In this, the "content" will be developed by some application and handed to syslogd (using *nix as an example device). syslogd will format the message adding in the PRI, timestamp, etc., and will hand it to the transport. - For udp transport, the "transport sender" will encapsulte it within udp and put it onto the wire. - For the case of tls, the "transport sender" will establish a new, or use an existing session with the "transport receiver". For discrepancies (if any) between the IP address of the "originator" and the "transport sender", the originator can use the [origin ip=...] SDE (Section 7.2). If this makes sense, then the mib counters can be: - the number of messages sent and received by the "syslog application" (syslogd) - the number of messages sent and received by the "transport sender" and "transport receiver". The tricky part here is that the counters of the "transport sender" and "transport receiver" are not going to be useful to counting messages that are relayed. Only the counters of the "syslog application" are going to be useful for that. To deal with that, I'll propose that that a table be set up to associate the messages sent to each relay destination. As an example from syslog.conf: kern.crit @loghost kern.info @loghost2.example.com The relay destinations will have to be enumerated. get "numOfRelayDests" would return "2" get "relayDest(1)" would return "loghost" get "relayDest(2)" would return "loghost2.example.com" What is to be sent to those destinations would have to be quantified. get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter) get "priOfRelayDest(2)" would return "6" (or "kern.info") When the device receives a "<2>..." syslog message (PRI=2, kern.crit), it will relay it to the two relay destinations. Then syslogOperationsMsgsReceived will be incremented by 1 syslogOperationsMsgsRelayed(0) will be incremented by 2 (the message went to two destinations) syslogOperationsMsgsRelayed(1) will be incremented by 1 (it sent one copy to "relayDest(1)" which is loghost) syslogOperationsMsgsRelayed(2) will be incremented by 1 (it sent another to ""relayDest(2)") syslogOperationsMsgsTransmitted will be incremented by 2 (it transmitted both) Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1 and on loghost2.example.com syslogOperationsMsgsReceived will also be incremented by 1. This gives an administrator a way to balance out messages sent and received. - If our device shows 3 messages relayed to loghost, and loghost shows 3 messages received, then we have a balance, even if MsgsTransmitted from our device is 482. - If our device shows 3 messages relayed but loghost shows 2 messages received, then we might have a discard on our device, or the message may have been dropped by some intermediary. - If our device shows 3 messages relayed but loghost shows 46 receieved then we likely have another device sending messages to loghost. To be clear on this, the counters for "transport sender" and "transport receiver" will NOT be associated with a peer - they will just count the number of messages sent and received. It will be up to the counters associated with the "syslog application" to associate the messages with peers so that the count of messages relayed will have some meaning. Does this make sense? As David said, we're not doing our job unless we're clear on the concepts, terminology and have a way to manage the devices. Thanks, Chris On Fri, 18 May 2007, tom.petch wrote: > Not sure where this draft is heading, but as a WG member, comments > > Tom Petch ---remainder elided for brevity--- _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue May 22 15:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqZu8-0000kO-5p; Tue, 22 May 2007 15:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqZu5-0000k2-RT for syslog@ietf.org; Tue, 22 May 2007 15:20:17 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqZu4-0008Gn-Jk for syslog@ietf.org; Tue, 22 May 2007 15:20:17 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7BC884013; Tue, 22 May 2007 15:20:14 -0400 (EDT) From: Sam Hartman To: Chris Lonvick Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> Date: Tue, 22 May 2007 15:20:14 -0400 In-Reply-To: (Chris Lonvick's message of "Tue, 22 May 2007 10:22:37 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org >>>>> "Chris" == Chris Lonvick writes: Your layer diagram makes sense. Chris> For discrepancies (if any) between the IP address of the Chris> "originator" and the "transport sender", the originator can Chris> use the [origin ip=...] SDE (Section 7.2). I'd assume that all data in the content notially is written relative to the originator, at least notionally. Now, sometimes, there will be complicated situations for example when the originator is split across boxes (imagine a system where syslog(2) was an RPC call rather than a library function that writes to a local socket) or where you are translating from one logging protocol to another (say a snmp implementation that generates a syslog message from a trap). _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue May 22 18:50:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqdBL-00081c-UM; Tue, 22 May 2007 18:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqdB5-0007vm-DF; Tue, 22 May 2007 18:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqdB4-0004RH-LN; Tue, 22 May 2007 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8A58E26E8A; Tue, 22 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HqdB4-0000wR-Es; Tue, 22 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 22 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-tc-mib-00.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Textual Conventions for Syslog Management Author(s) : G. Keeni Filename : draft-ietf-syslog-tc-mib-00.txt Pages : 13 Date : 2007-5-22 This MIB module defines textual conventions to represent facility and severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-tc-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-tc-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-22151424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-tc-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-tc-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-22151424.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From necojp@citiz.net Thu May 24 06:52:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrAwF-0003rj-Ol for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Thu, 24 May 2007 06:52:59 -0400 Received: from [222.171.201.235] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrAwD-0004Vh-U9 for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Thu, 24 May 2007 06:52:59 -0400 Received: from qxpnlf9 (unknown [159.56.173.174]) by smtp60 (Coremail) with SMTP id oIabeHSwu81DC9Qt.1 for ; Sat, 15 May 2004 08:22:57 +0800 (CST) X-Originating-IP: [159.56.173.174] Subject: =?iso-2022-jp?B?GyRCPWk/NDxUTU0kSzpHRSwhJiRPJDgkYSRGJE5JYjUkGyhC?= From: =?shift-jis?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 $B!V(B19$B:P$+$i(B50$BBe$^$G$Ne$OIb5$$r(B $B$7$F$$$k;v$K$J$j$^$9!#(B $B=w@-$,=w@-$G$"$k0Y$K(B $B$$$D$^$G$bNx$r$7$F$$$k$Y$-$@$H;W$$$^$9!#(B $B;d$?$A$O=i$a$F$NIb5$!"ITNQ$r1~1g$7(B $B/$75wN%$rCV$-$?$$!)(B $B%P%l$J$1$l$PNx?M$,M_$7$$!)(B $B;~4V$H$*6b$K$OM>M5$,$"$k!)(B $B!Z#3$D0J>eEv$F$O$^$k$J$i![(B http://www.aaqw.net/h/?wls $BIb5$$dITNQ$r$7$?$*$+$2$G(B $B5U$KIWIX4X78$,$&$^$/9T$/(BCASE$B$,B?$$$h$&$G$9!#(B $BLB$o$:$K0lJb$rF'$_=P$7$F2<$5$$!#(B $B!Z%9%?%C%U0lF1![(B $B(#(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B("(B $BG[?.Dd;_$O%3%A%i$^$G!#(B $B("(B DeliveryStop $B("(B refusal@mailmaster.dtdns.net $B("(B $B("!ZG[?.Dd;_$K!VG[?.Dd;_!W$H$*=q$-2<$5$$!#(B $B("7oL>$K!VG[?.Dd;_!W$H5-:\$5$l$F$$$J$$>l9g$O=hM}$,9T$($^$;$s!#(B $B(">0!"Dd;_$K$O?tF|4V$[$I$*;~4V$r$$$?$@$/>l9g$,$4$6$$$^$9!#(B $B("Dd;_$^$G?tF|!"?t2s%a!<%k$,Aw?.$5$l$k$3$H$,$4$6$$$^$9$,!"(B $B("2?B4$4N;>5$/$@$5$$!#(B $B(&(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B From syslog-bounces@lists.ietf.org Fri May 25 10:18:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hracg-0007ds-UF; Fri, 25 May 2007 10:18:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hracf-0007b2-N1 for syslog@ietf.org; Fri, 25 May 2007 10:18:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hrace-00082B-Dx for syslog@ietf.org; Fri, 25 May 2007 10:18:29 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 25 May 2007 07:18:28 -0700 X-IronPort-AV: i="4.14,580,1170662400"; d="scan'208"; a="157528510:sNHT40458096" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4PEIR0R020195; Fri, 25 May 2007 07:18:27 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4PEIQV2021607; Fri, 25 May 2007 14:18:26 GMT Date: Fri, 25 May 2007 07:18:26 -0700 (PDT) From: Chris Lonvick To: Sam Hartman Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 In-Reply-To: Message-ID: References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1400; t=1180102707; x=1180966707; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20Layer=20diagram=20&=20mib=20counters=20-=20was=3ARe=3 A=20[Syslog]=20Comments=20on=20=0A=20draft-ietf-syslog-protocol-20 |Sender:=20; bh=ASu49SB95mbz3dwXV6W4Q1TBvYKrzkaIzBpgBNeFev4=; b=nRunIAAwGfozF03Fe7umskK5c2v+NlUl4JepAMJ41VJpBg5UX4HpQRl/np0YLJZZjgKnmWTH q2zTbQ1BWOFtOySUbfMAGIswZa8SWh+p03qVRjxV4tl7+yVTL6xgzKMY; Authentication-Results: sj-dkim-8; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, On Tue, 22 May 2007, Sam Hartman wrote: >>>>>> "Chris" == Chris Lonvick writes: > > Your layer diagram makes sense. > Chris> For discrepancies (if any) between the IP address of the > Chris> "originator" and the "transport sender", the originator can > Chris> use the [origin ip=...] SDE (Section 7.2). > > > I'd assume that all data in the content notially is written relative > to the originator, at least notionally. Yes. > > Now, sometimes, there will be complicated situations for example when > the originator is split across boxes (imagine a system where syslog(2) > was an RPC call rather than a library function that writes to a local > socket) or where you are translating from one logging protocol to > another (say a snmp implementation that generates a syslog message > from a trap). I agree that's something that can happen. I don't think that anything should be written into the normative sections of the -protocol document to address that as it has nothing to do with the protocol on the wire. Perhaps a note in the security considerations section? With that: Rainer - Please update the document to reflect the new layering diagram and definitions. Glenn - Please use the same layering diagram in -device-mib and use the counters as suggested. All - Have a great weekend. :-) Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From necojp@citiz.net Fri May 25 16:43:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrgdF-0000GZ-F2 for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Fri, 25 May 2007 16:43:29 -0400 Received: from [222.171.204.50] (helo=a-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HrgdB-0006jT-50 for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Fri, 25 May 2007 16:43:29 -0400 Received: from orqai7 (unknown [125.38.120.190]) by smtp21 (Coremail) with SMTP id W4fJ9vmD5TRcwxO2.1 for ; Sun, 16 May 2004 17:59:20 +0800 (CST) X-Originating-IP: [125.38.120.190] Subject: =?iso-2022-jp?B?GyRCJTslVSVsN0c8KEhEGyhC?= From: =?shift-jis?B?aG90bWFpbF9jb20=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed $BF|K\:GBg%;%U%l7G<(HD!*(B $B%;%U%l$,$[$7$$$J$i!"!V$($C$A7O=P2q$$$N9->l!W$K$*G$$;!*(B $BqY$7%j%s%/$d!"$o$:$i$o$7$$9-9p$O0l@Z$J$7!*(B http://www.10wn.com/h/?hiroba2 From syslog-bounces@lists.ietf.org Sun May 27 07:24:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsGrS-000129-I4; Sun, 27 May 2007 07:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsGrR-00011C-Jg for syslog@ietf.org; Sun, 27 May 2007 07:24:33 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsGrQ-0004iT-Ip for syslog@ietf.org; Sun, 27 May 2007 07:24:33 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l4RBOHpE000806; Sun, 27 May 2007 20:24:17 +0900 (JST) Received: from [127.0.0.1] (kiras8.priv.cysol.co.jp [192.168.0.158]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l4RBNwsN024320; Sun, 27 May 2007 20:24:16 +0900 (JST) Message-ID: <46596A4E.3050702@cysols.com> Date: Sun, 27 May 2007 20:23:58 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Chris Lonvick Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: syslog , 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, I think that there are two separate issues that we are talking of here; - the layered model for syslog - the objects which we monitor I will send my comments on the layered model in a separate mail. As far as the Objects [MIB counters] are concerned I am reading 2 points (1) monitoring the relay activity. We want to have - a list of the relays - for every relay o the priority(ies) of the message that will be relayed to this relay o the number of messages transmitted to this relay (messagesTransmittedToRelay) - etc. (2) we do not need to monitor message received at the message-source level of granularity. The points are well taken. I could certainly use the features built using (1). Regarding (2)- monitoring messages at the message-source level of granularity is not difficult to implement. But there may be practical problems as there may be there may be a very large number of message sources - tracking the counters for each of the sources will be expensive etc. So I will agree with (2). I will add the new table definitions for (1) in the next version of the draft. Glenn > What I'm seeing is that our effort to add granularity for mib accounting > has made the document less clear. My apologies for that. > > Does the following make more sense: > > +---------------------+ +---------------------+ > | content | | content | > |---------------------| |---------------------| > | syslog application | | syslog application | (originator, > | | | | collector, relay) > |---------------------| |---------------------| > | syslog transport | | syslog transport | (transport sender, > | | | | (transport receiver) > +---------------------+ +---------------------+ > ^ ^ > | | > -------------------------- > > > In this, the "content" will be developed by some application and handed > to syslogd (using *nix as an example device). syslogd will format the > message adding in the PRI, timestamp, etc., and will hand it to the > transport. > - For udp transport, the "transport sender" will encapsulte it within udp > and put it onto the wire. > - For the case of tls, the "transport sender" will establish a new, or use > an existing session with the "transport receiver". > > For discrepancies (if any) between the IP address of the "originator" > and the "transport sender", the originator can use the [origin ip=...] > SDE (Section 7.2). > > > If this makes sense, then the mib counters can be: > - the number of messages sent and received by the "syslog application" > (syslogd) > - the number of messages sent and received by the "transport sender" and > "transport receiver". > The tricky part here is that the counters of the "transport sender" and > "transport receiver" are not going to be useful to counting messages > that are relayed. Only the counters of the "syslog application" are > going to be useful for that. To deal with that, I'll propose that that > a table be set up to associate the messages sent to each relay destination. > > As an example from syslog.conf: > > kern.crit @loghost > kern.info @loghost2.example.com > > The relay destinations will have to be enumerated. > get "numOfRelayDests" would return "2" > get "relayDest(1)" would return "loghost" > get "relayDest(2)" would return "loghost2.example.com" > > What is to be sent to those destinations would have to be quantified. > get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter) > get "priOfRelayDest(2)" would return "6" (or "kern.info") > > When the device receives a "<2>..." syslog message (PRI=2, kern.crit), > it will relay it to the two relay destinations. > Then > syslogOperationsMsgsReceived will be incremented by 1 > syslogOperationsMsgsRelayed(0) will be incremented by 2 > (the message went to two destinations) > syslogOperationsMsgsRelayed(1) will be incremented by 1 > (it sent one copy to "relayDest(1)" which is loghost) > syslogOperationsMsgsRelayed(2) will be incremented by 1 > (it sent another to ""relayDest(2)") > syslogOperationsMsgsTransmitted will be incremented by 2 > (it transmitted both) > > Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1 > and on loghost2.example.com syslogOperationsMsgsReceived will also be > incremented by 1. > > This gives an administrator a way to balance out messages sent and > received. > - If our device shows 3 messages relayed to loghost, and loghost shows 3 > messages received, then we have a balance, even if MsgsTransmitted from > our device is 482. > - If our device shows 3 messages relayed but loghost shows 2 messages > received, then we might have a discard on our device, or the message may > have been dropped by some intermediary. > - If our device shows 3 messages relayed but loghost shows 46 receieved > then we likely have another device sending messages to loghost. > > To be clear on this, the counters for "transport sender" and "transport > receiver" will NOT be associated with a peer - they will just count the > number of messages sent and received. It will be up to the counters > associated with the "syslog application" to associate the messages with > peers so that the count of messages relayed will have some meaning. > > Does this make sense? As David said, we're not doing our job unless > we're clear on the concepts, terminology and have a way to manage the > devices. > > Thanks, > Chris > > > > On Fri, 18 May 2007, tom.petch wrote: > >> Not sure where this draft is heading, but as a WG member, comments >> >> >> Tom Petch > ---remainder elided for brevity--- > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon May 28 01:18:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsXcn-0003I4-9F; Mon, 28 May 2007 01:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsXcm-0003DR-51 for syslog@ietf.org; Mon, 28 May 2007 01:18:32 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsXcl-00079M-2M for syslog@ietf.org; Mon, 28 May 2007 01:18:32 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l4S5I1pE011401; Mon, 28 May 2007 14:18:01 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l4S5HwsN006040; Mon, 28 May 2007 14:18:01 +0900 (JST) Message-ID: <465A6606.9000201@cysols.com> Date: Mon, 28 May 2007 14:17:58 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Chris Lonvick Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: syslog , 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, Sorry, but I have missed the point of the "layer diagram". It is not clear to me what the layers and the layering signify. There are 2 problems- (a) It seems odd that "content", an inert entity, sits on top of "application", an active entity. Is this OK ? In my understanding, in the layer model, we have layered entities each interact with the adjacent layer. Should we call it something else ? (b) It is not clear how the "layer diagram" will help in the understanding of the mib counters. Correct me if I am wrong - there is no way the transportSenderCounter and syslogApplicationSenderCounter will be different. Also, transportReceiverCounter and syslogApplicationReceiverCounter will always be the same. So we do not need an extra set of "transport" counters. Then the transport layer in the diagram is redundant. Having said that, I must add that if we are interested in the transport-level granularity, then and only then, the transport layer is significant, as far as the mib counters are concerned. Is that what we are looking for ? Glenn > What I'm seeing is that our effort to add granularity for mib accounting > has made the document less clear. My apologies for that. > > Does the following make more sense: > > +---------------------+ +---------------------+ > | content | | content | > |---------------------| |---------------------| > | syslog application | | syslog application | (originator, > | | | | collector, relay) > |---------------------| |---------------------| > | syslog transport | | syslog transport | (transport sender, > | | | | (transport receiver) > +---------------------+ +---------------------+ > ^ ^ > | | > -------------------------- > > > In this, the "content" will be developed by some application and handed > to syslogd (using *nix as an example device). syslogd will format the > message adding in the PRI, timestamp, etc., and will hand it to the > transport. > - For udp transport, the "transport sender" will encapsulte it within udp > and put it onto the wire. > - For the case of tls, the "transport sender" will establish a new, or use > an existing session with the "transport receiver". > > For discrepancies (if any) between the IP address of the "originator" > and the "transport sender", the originator can use the [origin ip=...] > SDE (Section 7.2). > > > If this makes sense, then the mib counters can be: > - the number of messages sent and received by the "syslog application" > (syslogd) > - the number of messages sent and received by the "transport sender" and > "transport receiver". > The tricky part here is that the counters of the "transport sender" and > "transport receiver" are not going to be useful to counting messages > that are relayed. Only the counters of the "syslog application" are > going to be useful for that. To deal with that, I'll propose that that > a table be set up to associate the messages sent to each relay destination. > > As an example from syslog.conf: > > kern.crit @loghost > kern.info @loghost2.example.com > > The relay destinations will have to be enumerated. > get "numOfRelayDests" would return "2" > get "relayDest(1)" would return "loghost" > get "relayDest(2)" would return "loghost2.example.com" > > What is to be sent to those destinations would have to be quantified. > get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter) > get "priOfRelayDest(2)" would return "6" (or "kern.info") > > When the device receives a "<2>..." syslog message (PRI=2, kern.crit), > it will relay it to the two relay destinations. > Then > syslogOperationsMsgsReceived will be incremented by 1 > syslogOperationsMsgsRelayed(0) will be incremented by 2 > (the message went to two destinations) > syslogOperationsMsgsRelayed(1) will be incremented by 1 > (it sent one copy to "relayDest(1)" which is loghost) > syslogOperationsMsgsRelayed(2) will be incremented by 1 > (it sent another to ""relayDest(2)") > syslogOperationsMsgsTransmitted will be incremented by 2 > (it transmitted both) > > Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1 > and on loghost2.example.com syslogOperationsMsgsReceived will also be > incremented by 1. > > This gives an administrator a way to balance out messages sent and > received. > - If our device shows 3 messages relayed to loghost, and loghost shows 3 > messages received, then we have a balance, even if MsgsTransmitted from > our device is 482. > - If our device shows 3 messages relayed but loghost shows 2 messages > received, then we might have a discard on our device, or the message may > have been dropped by some intermediary. > - If our device shows 3 messages relayed but loghost shows 46 receieved > then we likely have another device sending messages to loghost. > > To be clear on this, the counters for "transport sender" and "transport > receiver" will NOT be associated with a peer - they will just count the > number of messages sent and received. It will be up to the counters > associated with the "syslog application" to associate the messages with > peers so that the count of messages relayed will have some meaning. > > Does this make sense? As David said, we're not doing our job unless > we're clear on the concepts, terminology and have a way to manage the > devices. > > Thanks, > Chris > > > > On Fri, 18 May 2007, tom.petch wrote: > >> Not sure where this draft is heading, but as a WG member, comments >> >> >> Tom Petch > ---remainder elided for brevity--- > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue May 29 11:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht46z-0002CO-Bx; Tue, 29 May 2007 11:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht46y-0002CJ-F4 for syslog@ietf.org; Tue, 29 May 2007 11:59:52 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht46y-0002MF-1W for syslog@ietf.org; Tue, 29 May 2007 11:59:52 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007052915595101300iuddbe>; Tue, 29 May 2007 15:59:51 +0000 From: "David Harrington" To: "'Glenn M. Keeni'" , "'Chris Lonvick'" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <465A6606.9000201@cysols.com> Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentson draft-ietf-syslog-protocol-20 Date: Tue, 29 May 2007 11:59:33 -0400 Message-ID: <018b01c7a20a$5f8da700$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <465A6606.9000201@cysols.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: Aceg56UH7TOk9jATQ9KenFy+8ZEGawBHAUjA X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: 'syslog' , 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The IETF Management Framework makes a distcinction between management information and protocols used to carry information. The "content" layer provides an interface to the underlying instrumentation. A "content layer" concept is used in the Netconf architecture to represent this, and we carried that into this document to show a similar separation of the management information from the protocol. I believe there can be differences between the number of messages that "applications" request be sent and the number that is actually sent, because there can be error conditions that prevent a message from actually being sent. For syslog deployemnts that send the same message to multiple addresses and to a file for storage, do you count the number of "messages" or the number of transport endpoints? Do you count the file-storage destinations as having been snet, or only the messages that have been sent across a transport protocol? In addition, an implementation might contain multiple "applications" that use the same transport sending library. So the counting of messages can be different depending on where you count them. What I am interested in seeing is counters that are implemented in a relatively consistent manner across implementations, so an SNMP NMS can compare/contrast the values of the counters from different hosts/servers/applications/whatever. If one implementer increments the only "sent" counter when a request is made, and another increments the "sent" counter when each outgoing message is put on the wire, this can result in counters that are comparing apples to oranges. The conceptual layering helps when trying to write DESCRIPTION clauses that are consistent across implementations. Describing the conceptual layering keeps the DESCRIPTION at an abstract concept level to avoid having the standard dictate specific implementation decisions. We need to be able to specify where in the conceptual process a counter should be incremented, without dictating implementation software designs, in order to minimize ambiguity in the counter specification to eliminate inconsistent implementer-interpretations that make the counters non-interoperable across vendors. dbh > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Monday, May 28, 2007 1:18 AM > To: Chris Lonvick > Cc: syslog; 'Sam Hartman' > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > Commentson draft-ietf-syslog-protocol-20 > > Chris, > Sorry, but I have missed the point of the "layer diagram". > It is not clear to me what the layers and the layering signify. > There are 2 problems- > (a) It seems odd that "content", an inert entity, sits on top > of "application", an active entity. Is this OK ? In my > understanding, in the layer model, we have layered > entities each interact with the adjacent layer. Should we > call it something else ? > > (b) It is not clear how the "layer diagram" will help in the > understanding of the mib counters. Correct me if I am > wrong - there is no way the > transportSenderCounter and > syslogApplicationSenderCounter will be different. > Also, > transportReceiverCounter and > syslogApplicationReceiverCounter > will always be the same. So we do not need an extra > set of "transport" counters. Then the transport layer in > the diagram is redundant. > Having said that, I must add that if we are interested in > the transport-level granularity, then and only then, the > transport layer is significant, as far as the mib counters > are concerned. Is that what we are looking for ? > > > Glenn > > > > What I'm seeing is that our effort to add granularity for > mib accounting > > has made the document less clear. My apologies for that. > > > > Does the following make more sense: > > > > +---------------------+ +---------------------+ > > | content | | content | > > |---------------------| |---------------------| > > | syslog application | | syslog application | (originator, > > | | | | > collector, relay) > > |---------------------| |---------------------| > > | syslog transport | | syslog transport | > (transport sender, > > | | | | > (transport receiver) > > +---------------------+ +---------------------+ > > ^ ^ > > | | > > -------------------------- > > > > > > In this, the "content" will be developed by some > application and handed > > to syslogd (using *nix as an example device). syslogd will > format the > > message adding in the PRI, timestamp, etc., and will hand it to the > > transport. > > - For udp transport, the "transport sender" will encapsulte > it within udp > > and put it onto the wire. > > - For the case of tls, the "transport sender" will > establish a new, or use > > an existing session with the "transport receiver". > > > > For discrepancies (if any) between the IP address of the > "originator" > > and the "transport sender", the originator can use the > [origin ip=...] > > SDE (Section 7.2). > > > > > > If this makes sense, then the mib counters can be: > > - the number of messages sent and received by the "syslog > application" > > (syslogd) > > - the number of messages sent and received by the > "transport sender" and > > "transport receiver". > > The tricky part here is that the counters of the "transport > sender" and > > "transport receiver" are not going to be useful to counting > messages > > that are relayed. Only the counters of the "syslog > application" are > > going to be useful for that. To deal with that, I'll > propose that that > > a table be set up to associate the messages sent to each > relay destination. > > > > As an example from syslog.conf: > > > > kern.crit @loghost > > kern.info @loghost2.example.com > > > > The relay destinations will have to be enumerated. > > get "numOfRelayDests" would return "2" > > get "relayDest(1)" would return "loghost" > > get "relayDest(2)" would return "loghost2.example.com" > > > > What is to be sent to those destinations would have to be > quantified. > > get "priOfRelayDest(1)" would return "2" (from kern.crit > as the filter) > > get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > > When the device receives a "<2>..." syslog message (PRI=2, > kern.crit), > > it will relay it to the two relay destinations. > > Then > > syslogOperationsMsgsReceived will be incremented by 1 > > syslogOperationsMsgsRelayed(0) will be incremented by 2 > > (the message went to two destinations) > > syslogOperationsMsgsRelayed(1) will be incremented by 1 > > (it sent one copy to "relayDest(1)" which is loghost) > > syslogOperationsMsgsRelayed(2) will be incremented by 1 > > (it sent another to ""relayDest(2)") > > syslogOperationsMsgsTransmitted will be incremented by 2 > > (it transmitted both) > > > > Also, on loghost, syslogOperationsMsgsReceived will be > incremented by 1 > > and on loghost2.example.com syslogOperationsMsgsReceived > will also be > > incremented by 1. > > > > This gives an administrator a way to balance out messages sent and > > received. > > - If our device shows 3 messages relayed to loghost, and > loghost shows 3 > > messages received, then we have a balance, even if > MsgsTransmitted from > > our device is 482. > > - If our device shows 3 messages relayed but loghost shows > 2 messages > > received, then we might have a discard on our device, or > the message may > > have been dropped by some intermediary. > > - If our device shows 3 messages relayed but loghost shows > 46 receieved > > then we likely have another device sending messages to loghost. > > > > To be clear on this, the counters for "transport sender" > and "transport > > receiver" will NOT be associated with a peer - they will > just count the > > number of messages sent and received. It will be up to the > counters > > associated with the "syslog application" to associate the > messages with > > peers so that the count of messages relayed will have some meaning. > > > > Does this make sense? As David said, we're not doing our > job unless > > we're clear on the concepts, terminology and have a way to > manage the > > devices. > > > > Thanks, > > Chris > > > > > > > > On Fri, 18 May 2007, tom.petch wrote: > > > >> Not sure where this draft is heading, but as a WG member, comments > >> > >> > >> Tom Petch > > ---remainder elided for brevity--- > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog