From Washam.Fan@huaweisymantec.com Thu Apr 2 19:29:37 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0118628C25B for ; Thu, 2 Apr 2009 19:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0D6fE8Se9u6 for ; Thu, 2 Apr 2009 19:29:36 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 76C4A28C270 for ; Thu, 2 Apr 2009 19:21:49 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_sx9HBIoDhuLlq+a9hDs8Lg)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF00F4N0MX0V20@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 01 Apr 2009 17:20:59 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF008PU0MT3Y00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 01 Apr 2009 17:20:57 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 01 Apr 2009 17:20:53 +0800 From: WashamFan To: opsawg@ietf.org Message-id: Date: Wed, 01 Apr 2009 17:20:53 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Subject: [OPSAWG] FW:New Version Notification for draft-meng-fan-lock-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:29:37 -0000 This is a multi-part message in MIME format. --Boundary_(ID_sx9HBIoDhuLlq+a9hDs8Lg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi, This draft defines a MIB to monitor locks via different NM interfaces. It is used to monitor Netconf locks, Cops-Pr locks, and can be extended to support new interface locks. draft-ietf-netconf-monitoring now focus on Netconf locks mainly, IMO. It is relevant to netconf, cops-pr, mib, and so on, so I think it is an appropriate place to accommodate this draft. washam A new version of I-D, draft-meng-fan-lock-mib-01.txt has been successfuly submitted by Washam Fan and posted to the IETF repository. Filename: draft-meng-fan-lock-mib Revision: 01 Title: Definitions of Managed Objects for lock via network management protocols Creation_date: 2009-04-01 WG ID: Independent Submission Number_of_pages: 20 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It describes managed objects used for monitoring locks on a device, in paticularly, acquired or released by NETCONF and COPS-PR entities. The IETF Secretariat. --Boundary_(ID_sx9HBIoDhuLlq+a9hDs8Lg) Content-type: message/rfc822 Content-disposition: inline Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHE001UCY2GCN40@hstga02-in.huaweisymantec.com> for Washam.Fan@huaweisymantec.com; Wed, 01 Apr 2009 16:25:33 +0800 (CST) Received: from hstrg01-in.huaweisymantec.com ([172.26.3.37]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHE00HL9Y2C8800@hstml02-in.huaweisymantec.com> for Washam.Fan@huaweisymantec.com (ORCPT Washam.Fan@huaweisymantec.com); Wed, 01 Apr 2009 16:25:30 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by hstrg01-in.huaweisymantec.com (MOS 3.8.5-GA) id AHK07833; Wed, 01 Apr 2009 16:20:58 +0800 (CST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by hstrg01-in.huaweisymantec.com (MOS 3.8.5-GA) with ESMTP id AHK07831; Wed, 01 Apr 2009 16:20:56 +0800 (CST) Received: by core3.amsl.com (Postfix, from userid 30) id C21383A6844; Wed, 01 Apr 2009 01:24:21 -0700 (PDT) Date: Wed, 01 Apr 2009 01:24:21 -0700 (PDT) From: IETF I-D Submission Tool Subject: New Version Notification for draft-meng-fan-lock-mib-01 To: Washam.Fan@huaweisymantec.com Cc: mengjian@huaweisymantec.com Message-id: <20090401082421.C21383A6844@core3.amsl.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Junkmail-Status: score=10/55, host=hstrg01-in.huaweisymantec.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.49D324F4.010F:SCFSTAT3674418,ss=1,fgs=0, ip=64.170.98.32, so=2007-07-31 18:51:00, dmn=5.7.1/2008-09-02 X-Mirapoint-Loop-Id: a55414ff2061b75456f8a3ba79b51c50 A new version of I-D, draft-meng-fan-lock-mib-01.txt has been successfuly submitted by Washam Fan and posted to the IETF repository. Filename: draft-meng-fan-lock-mib Revision: 01 Title: Definitions of Managed Objects for lock via network management protocols Creation_date: 2009-04-01 WG ID: Independent Submission Number_of_pages: 20 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It describes managed objects used for monitoring locks on a device, in paticularly, acquired or released by NETCONF and COPS-PR entities. The IETF Secretariat. --Boundary_(ID_sx9HBIoDhuLlq+a9hDs8Lg)-- From SCHISHOL@nortel.com Fri Apr 3 05:59:30 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BC03A67D7 for ; Fri, 3 Apr 2009 05:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yTjUEBFThrK for ; Fri, 3 Apr 2009 05:59:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EB7593A6862 for ; Fri, 3 Apr 2009 05:59:08 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n33D07a07014; Fri, 3 Apr 2009 13:00:07 GMT 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: Fri, 3 Apr 2009 08:59:50 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B418EE1A3E@zcarhxm2.corp.nortel.com> In-Reply-To: <20090323165337.GA15855@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Proposed update to syslog Alarm Thread-Index: AcmsDih5tWsd6WE4QSa4IHoZbE2QBwITPrlA References: <713043CE8B8E1348AF3C546DBE02C1B41824B2E0@zcarhxm2.corp.nortel.com> <20090201133347.GA18098@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B418C6CA06@zcarhxm2.corp.nortel.com> <20090323135224.GA14442@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B418C6CEAD@zcarhxm2.corp.nortel.com> <20090323165337.GA15855@elstar.local> From: "Sharon Chisholm" To: "Juergen Schoenwaelder" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Proposed update to syslog Alarm X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:59:30 -0000 Hi It is acknowledged that resourceOID does not work in all circumstances but the idea of leaving it in is that it is understood by the majority of SNMP users. The URI approach was introduced to cover the cases that OID could not. So, we are using the SNMP URI approach either way, the question is whether to also keep the resourceOID. In my view, using OIDS, which are universally understood, is something a lot of implementations will want to do so it would be nice to have a standard way to do that, but I'll go with working group consensus.=20 So far I have heard Dave H - remove it Sharon - keep it Juergen - remove it or align it to other work So, if there are no other views I would suggest that we remove it. Sharon=20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, March 23, 2009 12:54 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Proposed update to syslog Alarm On Mon, Mar 23, 2009 at 05:04:41PM +0100, Sharon Chisholm wrote: =20 > So, are you OK with leaving all three in the document? Once again, resourceOID is broken. If you leave it, you have to fix it. My preference would be to either (a) use the SNMP URI scheme or (b) use the the SNMP to SYSLOG mappings also defined as part of the OPSAWG working group. If you plan to invent a third solution, make sure you have strong arguments; I prefer to reuse existing solutions. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Apr 3 12:42:31 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90BF3A6827 for ; Fri, 3 Apr 2009 12:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYcLL2JYf1UG for ; Fri, 3 Apr 2009 12:42:31 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 0E1793A67FB for ; Fri, 3 Apr 2009 12:42:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JBfKCRhOBa7CF1QhYZ+WRN39biCg/sBxJ05CIRY1045+oJCRdrMG67+AtNvcfltv; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.109] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LppIb-00018E-L1 for opsawg@ietf.org; Fri, 03 Apr 2009 15:43:33 -0400 Message-ID: <003a01c9b494$b874ed80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B41824B2E0@zcarhxm2.corp.nortel.com><20090201133347.GA18098@elstar.local><713043CE8B8E1348AF3C546DBE02C1B418C6CA06@zcarhxm2.corp.nortel.com><20090323135224.GA14442@elstar.local><713043CE8B8E1348AF3C546DBE02C1B418C6CEAD@zcarhxm2.corp.nortel.com><20090323165337.GA15855@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B418EE1A3E@zcarhxm2.corp.nortel.com> Date: Fri, 3 Apr 2009 12:45:19 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173584337c6ac87dc7685a79a867367b226350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.109 Subject: Re: [OPSAWG] Proposed update to syslog Alarm X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 19:42:31 -0000 Hi - > From: "Sharon Chisholm" > To: "Juergen Schoenwaelder" > Cc: > Sent: Friday, April 03, 2009 5:59 AM > Subject: Re: [OPSAWG] Proposed update to syslog Alarm ... > It is acknowledged that resourceOID does not work in all circumstances > but the idea of leaving it in is that it is understood by the majority > of SNMP users. The URI approach was introduced to cover the cases that > OID could not. So, we are using the SNMP URI approach either way, the > question is whether to also keep the resourceOID. In my view, using > OIDS, which are universally understood, is something a lot of > implementations will want to do so it would be nice to have a standard > way to do that, but I'll go with working group consensus. > > So far I have heard > > Dave H - remove it > Sharon - keep it > Juergen - remove it or align it to other work > > So, if there are no other views I would suggest that we remove it. I'd prefer removal, but would find it acceptable to leave it in if it were made clear that resourceOID could only be used for the context "", and MUST NOT be used for any other context, and that in all other cases SNMP URI MUST be used instead. Randy From j.schoenwaelder@jacobs-university.de Mon Apr 6 09:30:24 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231C53A6B04 for ; Mon, 6 Apr 2009 09:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NplxynDrlQdH for ; Mon, 6 Apr 2009 09:30:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 58BEE3A6C75 for ; Mon, 6 Apr 2009 09:30:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06E8AC0013 for ; Mon, 6 Apr 2009 18:31:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9kC71FFPv2yi; Mon, 6 Apr 2009 18:31:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 510A8C000A; Mon, 6 Apr 2009 18:31:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 62EBBA5FF05; Mon, 6 Apr 2009 18:31:11 +0200 (CEST) Date: Mon, 6 Apr 2009 18:31:11 +0200 From: Juergen Schoenwaelder To: "opsawg@ietf.org" Message-ID: <20090406163111.GA21517@elstar.local> Mail-Followup-To: "opsawg@ietf.org" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 16:30:24 -0000 On Thu, Mar 26, 2009 at 06:34:04PM +0100, Scott O. Bradner wrote: > > this starts a WGLC on > draft-ietf-opsawg-syslog-snmp-02.txt > and > draft-ietf-opsawg-syslog-msg-mib-02.txt > > please send any comments to the list by April 13th Please note the active WGLC. Also statements that you reviewed the documents and are fine with them are helpful input for the chairs. There is still one week left but Easter holidays are coming up quickly... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Apr 6 14:20:38 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076FD3A6B02 for ; Mon, 6 Apr 2009 14:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79XBcXFkb6gw for ; Mon, 6 Apr 2009 14:20:32 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2D1423A682D for ; Mon, 6 Apr 2009 14:20:32 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EEC2C616022; Mon, 6 Apr 2009 23:21:31 +0200 (CEST) Date: Mon, 06 Apr 2009 23:21:31 +0200 (CEST) Message-Id: <20090406.232131.231758431.mbj@tail-f.com> To: sob@harvard.edu From: Martin Bjorklund In-Reply-To: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 21:20:38 -0000 Hi, sob@harvard.edu (Scott O. Bradner) wrote: > > this starts a WGLC on > draft-ietf-opsawg-syslog-snmp-02.txt I have read this document, and my previous issues are now addressed. There is some new text in section 4 (Relationship to the SYSLOG-MSG-MIB). The first paragraph gives the impression that the section will describe how the two syslog/snmp documents can be used to create tunnels. But the rest of the section does not mention the other document at all. Minor nits: 3.2: s/as as/as an/ 5: s/show below/shown below/ > draft-ietf-opsawg-syslog-msg-mib-02.txt I have read this document, and my previous issues are now addressed. Section 6 describes how the two documents are related. It says: As a consequence, an SNMP management application should use trap-directed polling to determine whether a received SNMP notification did include all SD-IDs of a SYSLOG message. But is trap-directed polling really necessary, since the notification contains syslogMsgFlags which may set the bit 'truncated'? Hmm.. from the description of 'truncated' it seems it applies to trucation of syslogMsgMsg only, so maybe it can be set, but still all SD-params are included? But then the last sentence seems to contradict this: "For syslog messages without structured data element parameters that were not truncated by the converter, none of the bits is set." /martin From j.schoenwaelder@jacobs-university.de Tue Apr 7 04:31:16 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FEC3A6D66 for ; Tue, 7 Apr 2009 04:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZvGh4YCniFK for ; Tue, 7 Apr 2009 04:31:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DCBF63A68D9 for ; Tue, 7 Apr 2009 04:31:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCA93C0021; Tue, 7 Apr 2009 13:32:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NDe4i5PR1kIj; Tue, 7 Apr 2009 13:32:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F0B3C000A; Tue, 7 Apr 2009 13:32:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3308EA64D51; Tue, 7 Apr 2009 13:31:54 +0200 (CEST) Date: Tue, 7 Apr 2009 13:31:54 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090407113154.GA29263@elstar.local> Mail-Followup-To: Martin Bjorklund , "opsawg@ietf.org" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406.232131.231758431.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090406.232131.231758431.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 11:31:16 -0000 On Mon, Apr 06, 2009 at 11:21:31PM +0200, Martin Bjorklund wrote: > There is some new text in section 4 (Relationship to the > SYSLOG-MSG-MIB). The first paragraph gives the impression that the > section will describe how the two syslog/snmp documents can be used to > create tunnels. But the rest of the section does not mention the > other document at all. I suggest to add "and [I-D.ietf-opsawg-syslog-msg-mib]" to the 1st sentence in the second paragraph so things become clearer: A SYSLOG receiver supporting an SNMP notification originator implementing this specification and [I-D.ietf-opsawg-syslog-msg-mib] SHOULD translate received SYSLOG messages containing SNMP notifications back into the SNMP notifications. > Minor nits: 3.2: s/as as/as an/ > 5: s/show below/shown below/ Fixed in my sources. > Section 6 describes how the two documents are related. It says: > > As a consequence, > an SNMP management application should use trap-directed polling to > determine whether a received SNMP notification did include all SD-IDs > of a SYSLOG message. > > But is trap-directed polling really necessary, since the notification > contains syslogMsgFlags which may set the bit 'truncated'? There are two issues here: The truncated bit it set when the SYSLOG implementation truncates an incoming SYSLOG message due to resource constraints and this usually affects the free form message part since it comes last. The other issue is the number of SD-IDs that can be included in a notification, which is in principle SNMP transport dependent and thus can't be captured in a single flag. If we do not want to resort to trap-directed polling, we could include an additional object indicating the number of SD-IDs in the mandatory to send notification objects and then the receiver can easily check whether the SD-IDs received are complete: syslogMsgSDIDs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SD-IDs contained in the syslog message. This object allows a notification receiver to check whether all SD-IDs have been carried in a notification." REFERENCE "RFC5424: The Syslog Protocol (section 6.3.3)" Such an object renders the sdparams bit useless and since the truncated bit only reports truncation of incoming messages but no truncation that has happened on the path already, we might do away with the syslogMsgFlags in favour of the syslogMsgSDIDs object defined above. I am open for this change. What do others think about this issue? > Hmm.. from the description of 'truncated' it seems it applies to > trucation of syslogMsgMsg only, so maybe it can be set, but still all > SD-params are included? But then the last sentence seems to > contradict this: "For syslog messages without structured data element > parameters that were not truncated by the converter, none of the bits > is set." I think the statement is actually correct but this text will change anyway depending on the adoption of the suggestion outlined above. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Apr 7 04:34:43 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98103A6DCE for ; Tue, 7 Apr 2009 04:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGhlCzll2KlP for ; Tue, 7 Apr 2009 04:34:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BEA333A693D for ; Tue, 7 Apr 2009 04:34:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0031CC0021; Tue, 7 Apr 2009 13:35:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KXgRYkJEZhpO; Tue, 7 Apr 2009 13:35:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2F52C000A; Tue, 7 Apr 2009 13:35:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF03CA64D99; Tue, 7 Apr 2009 13:35:25 +0200 (CEST) Date: Tue, 7 Apr 2009 13:35:25 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090407113525.GB29263@elstar.local> Mail-Followup-To: WashamFan , Martin Bjorklund , "sob@harvard.edu" , "opsawg@ietf.org" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406.232131.231758431.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 11:34:43 -0000 On Tue, Apr 07, 2009 at 05:48:48AM +0200, WashamFan wrote: > I also suggest clarify when to use polling. If I understand > correctly, if sdparams is not set, then polling is not > needed. otherwise, polling is needed no matter SNMP notification > includes SD-IDs or not. Cause we can not dertermine if the > notification includes SD-IDs fully or partially. Yes. But see my response to Martin for a possible way to avoid polling to check whether all SD-IDs have been received. > One more thing: > The title of section 6 should be "Relationship to SNMP Notification to SYSLOG Mappings". Fixed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Apr 7 05:09:31 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0183A6DC0 for ; Tue, 7 Apr 2009 05:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFeDyzkaeKUc for ; Tue, 7 Apr 2009 05:09:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E97423A6DAD for ; Tue, 7 Apr 2009 05:09:29 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FFF7C0021; Tue, 7 Apr 2009 14:10:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PtKoJL6l+c1l; Tue, 7 Apr 2009 14:10:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E696CC000A; Tue, 7 Apr 2009 14:10:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ECF1AA64E49; Tue, 7 Apr 2009 14:10:17 +0200 (CEST) Date: Tue, 7 Apr 2009 14:10:17 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090407121017.GC29263@elstar.local> Mail-Followup-To: WashamFan , "opsawg@ietf.org" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406163111.GA21517@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 12:09:31 -0000 On Tue, Apr 07, 2009 at 09:52:42AM +0200, WashamFan wrote: > But some new issues I'd like to raise at this point: > > (1)wrt/ the figure in page 6, there can be many SNMP notification > originators, but why not allow for many SYSLOG collectors? The figure shows a "common scenario" - it does not limit installations to exactly three notification originators and a single collector. But I can easily change the figure to show two syslog collectors if that helps (but I still do not include proxies and the many other combinations that are possible). It might also make sense to change the figure so that the flow is from left to right: +------------+ +-------------------+ |snmp | snmp | | syslog +---------+ |notification| notification | +-------------+ | message |syslog | |originator |------------->| |syslog sender| |-------->|collector| +------------+ | +-------------+ | +---------+ +------------+ | +------------+ | |snmp | snmp | |snmp | | syslog +---------+ |notification| notification | |notification| | message |syslog | |originator |------------->| |receiver | |-------->|collector| +------------+ | +------------+ | +---------+ +------------+ | snmp-to-syslog | |snmp | snmp | translator | |notification| notification | | |originator |------------->| | +------------+ +-------------------+ > (2) information extracted from SNMP notification should be reflected > in snmp SDE only or some other places. for example, "origin" SD-ID can refect > SNMP notif, which mentioned in sec3.2. What about SYSLOG HEADER, > MSGID, for example, represents the type of SNMP notif or the SYSLOG > messages, in the latter case, all SYSLOG messages containing snmp SDE > should have the same MSGID. I do not understand your question. Please elaborate or suggest what should be changed and where. > (3) How about one SYSLOG message contains multiplex snmp SDEs, is it > allowed? What are "multiplex snmp SDEs"? > nit: > 3rd sentence, 1st para, sec2.2: > RFCxxxx should be RFC5424. Fixed. > > > and > > > draft-ietf-opsawg-syslog-msg-mib-02.txt > > > > > I reviewed again, and found it has addressed my previous concerns. > But, there are some concerns wrt/ consistency with syslog-snmp-02: > > (1)snmp-to-syslog translator is defined in syslog-snmp-02, > but no syslog-to-snmp translator definition. I wrote this document following the usual MIB template and I did not feel a special term would be needed from an SNMP perspective. Do you think it is needed? Or are you missing a figure like the one above showing how SYSLOG messages can be accessed via the SYSLOG-MSG-MIB? > (2)There should be a counterpart to para2, sec7 in syslog-snmp-02 > in this doc. I do not think there is an access control mechanism for SYSLOG so I am not sure what you are looking for. Can you elaborate? > some nits: > (3)sec4, para5: > > The syslogMsgTable contains one entry for each recorded SYSLOG > message. The basic fields of SYSLOG messages are represented in > different columns of the conceptual table. > > Actually, a flag syslogMsgFlags is also in the table, how about: > The basic fields of SYSLOG messages are represented in > different columns of the conceptual table as well as a flag called syslogMsgFlags. Fixed. > (4) > --syslogMsgObjects(1) > | > +--syslogMsgSDTable(3) > | > +--syslogMsgSDEntry(1) [syslogMsgIndex, > | syslogMsgSDParamIndex <--- comma lacked > | syslogMsgSDID, > | syslogMsgSDParamName] > | > +-- Unsigned32 syslogMsgSDParamIndex(1) > +-- DisplayString syslogMsgSDID(2) > +-- DisplayString syslogMsgSDParamName(3) > +-- SnmpAdminString syslogMsgSDParamValue(4) Fixed. > (5)I-D.ietf-syslog-protocol and I-D.ietf-syslog-tc-mib should > be substituted with corresponding RFCs. Done already when the RFCs appeared. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Apr 7 12:53:20 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D893A6800 for ; Tue, 7 Apr 2009 12:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ+GfCo4oTv6 for ; Tue, 7 Apr 2009 12:53:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7F3453A693C for ; Tue, 7 Apr 2009 12:53:18 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9FB91616005; Tue, 7 Apr 2009 21:54:23 +0200 (CEST) Date: Tue, 07 Apr 2009 21:54:22 +0200 (CEST) Message-Id: <20090407.215422.190876419.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090407113154.GA29263@elstar.local> References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406.232131.231758431.mbj@tail-f.com> <20090407113154.GA29263@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:53:20 -0000 Juergen Schoenwaelder wrote: > On Mon, Apr 06, 2009 at 11:21:31PM +0200, Martin Bjorklund wrote: > > > There is some new text in section 4 (Relationship to the > > SYSLOG-MSG-MIB). The first paragraph gives the impression that the > > section will describe how the two syslog/snmp documents can be used to > > create tunnels. But the rest of the section does not mention the > > other document at all. > > I suggest to add "and [I-D.ietf-opsawg-syslog-msg-mib]" to the 1st > sentence in the second paragraph so things become clearer: > > A SYSLOG receiver supporting an SNMP notification originator > implementing this specification and [I-D.ietf-opsawg-syslog-msg-mib] > SHOULD translate received SYSLOG messages containing SNMP > notifications back into the SNMP notifications. The other document describes this tunneling in somewhat more details. Can this document simply refer to the relevant section in the other document instead? > > Section 6 describes how the two documents are related. It says: > > > > As a consequence, > > an SNMP management application should use trap-directed polling to > > determine whether a received SNMP notification did include all SD-IDs > > of a SYSLOG message. > > > > But is trap-directed polling really necessary, since the notification > > contains syslogMsgFlags which may set the bit 'truncated'? > > There are two issues here: The truncated bit it set when the SYSLOG > implementation truncates an incoming SYSLOG message due to resource > constraints and this usually affects the free form message part since > it comes last. Ok. > The other issue is the number of SD-IDs that can be > included in a notification, which is in principle SNMP transport > dependent and thus can't be captured in a single flag. > > If we do not > want to resort to trap-directed polling, This would still be trap-directed polling, right? You get the trap, check you got all SD-params, and if not, you poll the device. > we could include an > additional object indicating the number of SD-IDs in the mandatory to > send notification objects and then the receiver can easily check > whether the SD-IDs received are complete: > > syslogMsgSDIDs OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of SD-IDs contained in the syslog > message. This object allows a notification > receiver to check whether all SD-IDs have been > carried in a notification." > REFERENCE > "RFC5424: The Syslog Protocol (section 6.3.3)" > > Such an object renders the sdparams bit useless and since the > truncated bit only reports truncation of incoming messages but no > truncation that has happened on the path already, we might do away > with the syslogMsgFlags in favour of the syslogMsgSDIDs object > defined above. On its own, this object does not cover the case that the implementation truncated the syslogMsgMsg, but kept all SD params (maybe there were none). So I think this object should be added, but also that the syslogMsgFlags is needed (with just the 'truncated' bit). /martin From Washam.Fan@huaweisymantec.com Tue Apr 7 13:54:03 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED5D28C101 for ; Tue, 7 Apr 2009 13:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSvF9u7aCByD for ; Tue, 7 Apr 2009 13:54:02 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 3095D3A688D for ; Tue, 7 Apr 2009 13:54:02 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHP00ACGP9FO660@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Tue, 07 Apr 2009 11:48:53 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHP00E5SP9C6F00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Tue, 07 Apr 2009 11:48:50 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 07 Apr 2009 11:48:48 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Tue, 07 Apr 2009 11:48:48 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090406.232131.231758431.mbj@tail-f.com> References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406.232131.231758431.mbj@tail-f.com> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 20:54:03 -0000 > Hi, > > sob@harvard.edu (Scott O. Bradner) wrote: > > > > this starts a WGLC on > > draft-ietf-opsawg-syslog-snmp-02.txt > > I have read this document, and my previous issues are now addressed. > > There is some new text in section 4 (Relationship to the > SYSLOG-MSG-MIB). The first paragraph gives the impression that the > section will describe how the two syslog/snmp documents can be used to > create tunnels. But the rest of the section does not mention the > other document at all. +1 This section should be consistent with section 6 in syslog-msg-mib-02. > Minor nits: 3.2: s/as as/as an/ > 5: s/show below/shown below/ > > > draft-ietf-opsawg-syslog-msg-mib-02.txt > > I have read this document, and my previous issues are now addressed. > > Section 6 describes how the two documents are related. It says: > > As a consequence, > an SNMP management application should use trap-directed polling to > determine whether a received SNMP notification did include all SD-IDs > of a SYSLOG message. > > But is trap-directed polling really necessary, since the notification > contains syslogMsgFlags which may set the bit 'truncated'? > > Hmm.. from the description of 'truncated' it seems it applies to > trucation of syslogMsgMsg only, so maybe it can be set, but still all > SD-params are included? But then the last sentence seems to > contradict this: "For syslog messages without structured data element > parameters that were not truncated by the converter, none of the bits > is set." I also suggest clarify when to use polling. If I understand correctly, if sdparams is not set, then polling is not needed. otherwise, polling is needed no matter SNMP notification includes SD-IDs or not. Cause we can not dertermine if the notification includes SD-IDs fully or partially. One more thing: The title of section 6 should be "Relationship to SNMP Notification to SYSLOG Mappings". washam From j.schoenwaelder@jacobs-university.de Tue Apr 7 14:03:01 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3922C3A698D for ; Tue, 7 Apr 2009 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18wxYD1joFfe for ; Tue, 7 Apr 2009 14:03:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4B0233A6A8F for ; Tue, 7 Apr 2009 14:01:54 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA9F5C0018; Tue, 7 Apr 2009 23:03:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V-Doe8DKyX6L; Tue, 7 Apr 2009 23:02:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9EF5C000A; Tue, 7 Apr 2009 23:02:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B3E06A65517; Tue, 7 Apr 2009 23:02:41 +0200 (CEST) Date: Tue, 7 Apr 2009 23:02:41 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090407210241.GA205@elstar.local> Mail-Followup-To: Martin Bjorklund , "opsawg@ietf.org" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406.232131.231758431.mbj@tail-f.com> <20090407113154.GA29263@elstar.local> <20090407.215422.190876419.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090407.215422.190876419.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 21:03:01 -0000 On Tue, Apr 07, 2009 at 09:54:22PM +0200, Martin Bjorklund wrote: > > I suggest to add "and [I-D.ietf-opsawg-syslog-msg-mib]" to the 1st > > sentence in the second paragraph so things become clearer: > > > > A SYSLOG receiver supporting an SNMP notification originator > > implementing this specification and [I-D.ietf-opsawg-syslog-msg-mib] > > SHOULD translate received SYSLOG messages containing SNMP > > notifications back into the SNMP notifications. > > The other document describes this tunneling in somewhat more details. > Can this document simply refer to the relevant section in the other > document instead? I think the two sections say something slightly different. I tried to keep a loose binding between the two documents, but that probably makes it also somewhat more difficult. I am not sure what to do. Do you think there is something essential missing or are we talking about how to present things best? > > The other issue is the number of SD-IDs that can be > > included in a notification, which is in principle SNMP transport > > dependent and thus can't be captured in a single flag. > > > > If we do not > > want to resort to trap-directed polling, > > This would still be trap-directed polling, right? You get the trap, > check you got all SD-params, and if not, you poll the device. The difference is that you only have to poll in case you missed some SD-IDs. This can make a difference, in particular if you use SNMP transports that support the meanwhile even for UDP recommended 1472 octet SNMP message sizes. > > we could include an > > additional object indicating the number of SD-IDs in the mandatory to > > send notification objects and then the receiver can easily check > > whether the SD-IDs received are complete: > > > > syslogMsgSDIDs OBJECT-TYPE > > SYNTAX Unsigned32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of SD-IDs contained in the syslog > > message. This object allows a notification > > receiver to check whether all SD-IDs have been > > carried in a notification." > > REFERENCE > > "RFC5424: The Syslog Protocol (section 6.3.3)" > > > > Such an object renders the sdparams bit useless and since the > > truncated bit only reports truncation of incoming messages but no > > truncation that has happened on the path already, we might do away > > with the syslogMsgFlags in favour of the syslogMsgSDIDs object > > defined above. > > On its own, this object does not cover the case that the > implementation truncated the syslogMsgMsg, but kept all SD params > (maybe there were none). So I think this object should be added, but > also that the syslogMsgFlags is needed (with just the 'truncated' bit). There is a significant price for this bit and note other SYSLOG components such as relays can happily truncate without this being communicated to anyone. I am not sure the price of ~10 bytes to carry this truncated bit is really justified to indicate truncation in the MIB instrumentation while we happily ignore truncation that happens before on the SYSLOG forwarding path. Perhaps we should drop the truncation text and instead recommend that SNMP transports should support large message sizes, that is 1472 octets instead of just 484 octets for UDP, with a pointer to RFC 3417 section 3.2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Apr 7 14:16:22 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402393A6A88 for ; Tue, 7 Apr 2009 14:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvA3GNdhMWOW for ; Tue, 7 Apr 2009 14:16:21 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2B95C3A6A7B for ; Tue, 7 Apr 2009 14:16:21 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5CD2F616005; Tue, 7 Apr 2009 23:17:26 +0200 (CEST) Date: Tue, 07 Apr 2009 23:17:25 +0200 (CEST) Message-Id: <20090407.231725.220821046.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090407210241.GA205@elstar.local> References: <20090407113154.GA29263@elstar.local> <20090407.215422.190876419.mbj@tail-f.com> <20090407210241.GA205@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 21:16:22 -0000 Juergen Schoenwaelder wrote: > On Tue, Apr 07, 2009 at 09:54:22PM +0200, Martin Bjorklund wrote: > > > > I suggest to add "and [I-D.ietf-opsawg-syslog-msg-mib]" to the 1st > > > sentence in the second paragraph so things become clearer: > > > > > > A SYSLOG receiver supporting an SNMP notification originator > > > implementing this specification and [I-D.ietf-opsawg-syslog-msg-mib] > > > SHOULD translate received SYSLOG messages containing SNMP > > > notifications back into the SNMP notifications. > > > > The other document describes this tunneling in somewhat more details. > > Can this document simply refer to the relevant section in the other > > document instead? > > I think the two sections say something slightly different. My understanding, which might be wrong, was that the section in msg-mib describes how two create two types of tunnels, and the section in syslog-snmp describes one of these tunnels. > I tried to > keep a loose binding between the two documents, but that probably > makes it also somewhat more difficult. I am not sure what to do. Do > you think there is something essential missing or are we talking about > how to present things best? I just noted that it seems that the msg-mib section is a superset of the syslog-snmp section, and wonder if this was the intention. One difference is that the syslog-snmp section says that an implementation SHOULD translate back; msg-mib says that an implementation "may be configured to" translate back. > There is a significant price for this bit and note other SYSLOG > components such as relays can happily truncate without this being > communicated to anyone. I am not sure the price of ~10 bytes to carry > this truncated bit is really justified to indicate truncation in the > MIB instrumentation while we happily ignore truncation that happens > before on the SYSLOG forwarding path. > > Perhaps we should drop the truncation text and instead recommend that > SNMP transports should support large message sizes, that is 1472 > octets instead of just 484 octets for UDP, with a pointer to RFC 3417 > section 3.2. I don't mind making things simpler, if it is consistent with the rest of the syslog architecture. It would be good to get some feedback on this proposal from some syslog people. /martin From Washam.Fan@huaweisymantec.com Tue Apr 7 20:36:40 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0413A687C for ; Tue, 7 Apr 2009 20:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKQpibhpUJEn for ; Tue, 7 Apr 2009 20:36:39 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id EB2543A6829 for ; Tue, 7 Apr 2009 20:36:38 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHR00ADVJERBA80@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 08 Apr 2009 11:37:42 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHR0056LJEPYO00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 08 Apr 2009 11:37:39 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 08 Apr 2009 11:37:37 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Wed, 08 Apr 2009 11:37:37 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090407121017.GC29263@elstar.local> References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406163111.GA21517@elstar.local> <20090407121017.GC29263@elstar.local> Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 03:36:40 -0000 > > (2) information extracted from SNMP notification should be reflected > > in snmp SDE only or some other places. for example, "origin" SD-ID > can refect > > SNMP notif, which mentioned in sec3.2. What about SYSLOG HEADER, > > MSGID, for example, represents the type of SNMP notif or the SYSLOG > > messages, in the latter case, all SYSLOG messages containing snmp SDE > > should have the same MSGID. > > I do not understand your question. Please elaborate or suggest what > should be changed and where. Please bear with me, I made a mistake. Just ignoring that above. Still I suggest more text for SYSLOG specific HEADER like this: "This specification does not mandate particular values for these fields; however, for consistency, SYSLOG originators MUST use the same values for APP-NAME, PROCID, and MSGID fields for every message that is sent, whichever values are chosen. To allow for the possibility of multiple originators per host, the combination of APP-NAME, PROCID, and MSGID MUST be unique for each such originator. If an originator daemon is restarted, it MAY use a new PROCID for what is otherwise the same originator but MUST continue to use the same APP-NAME and MSGID." > > (3) How about one SYSLOG message contains multiplex snmp SDEs, is it > > allowed? > > What are "multiplex snmp SDEs"? Can one SYSLOG message contain many snmp SDEs to convey many SNMP notifications together? I don't think it is clear in current text. > > (1)snmp-to-syslog translator is defined in syslog-snmp-02, > > but no syslog-to-snmp translator definition. > > I wrote this document following the usual MIB template and I did not > feel a special term would be needed from an SNMP perspective. Do you > think it is needed? Or are you missing a figure like the one above > showing how SYSLOG messages can be accessed via the SYSLOG-MSG-MIB? Actually, I can live with current text. But I have a feeling, at some aspects, syslog-snmp is verbose, like the figure, the definition; at the others, syslog-msg-mib is verbose, like "tunneling" ;) > > (2)There should be a counterpart to para2, sec7 in syslog-snmp-02 > > in this doc. > > I do not think there is an access control mechanism for SYSLOG so I am > not sure what you are looking for. Can you elaborate? If I understand correctly, para2, sec7 recommends snmp-syslog-translator should enforce consistent policy with SNMP. And the similar text should be added to recommends syslog-snmp-translator should enfore consistent policy with SYSLOG. IMO, SYSLOG does have its rules to say which host is expected to receive which part of messages(filters). So, when SYSLOG messages are converted to SNMP notification, the same rules should apply. washam From j.schoenwaelder@jacobs-university.de Wed Apr 8 05:30:42 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D573A6AB3 for ; Wed, 8 Apr 2009 05:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE1AlTka6COt for ; Wed, 8 Apr 2009 05:30:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DA66A3A68C5 for ; Wed, 8 Apr 2009 05:30:40 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6141BC0018; Wed, 8 Apr 2009 14:31:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DUce8S8-rpeQ; Wed, 8 Apr 2009 14:31:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87DB8C0014; Wed, 8 Apr 2009 14:31:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0CC08A65EA7; Wed, 8 Apr 2009 14:31:27 +0200 (CEST) Date: Wed, 8 Apr 2009 14:31:27 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090408123127.GC1060@elstar.local> Mail-Followup-To: WashamFan , "opsawg@ietf.org" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406163111.GA21517@elstar.local> <20090407121017.GC29263@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 12:30:42 -0000 On Wed, Apr 08, 2009 at 05:37:37AM +0200, WashamFan wrote: > Still I suggest more text for SYSLOG specific HEADER like this: > "This specification does > not mandate particular values for these fields; however, for > consistency, SYSLOG originators MUST use the same values for APP-NAME, > PROCID, and MSGID fields for every message that is > sent, whichever values are chosen. To allow for the possibility of > multiple originators per host, the combination of APP-NAME, PROCID, > and MSGID MUST be unique for each such originator. If an originator > daemon is restarted, it MAY use a new PROCID for what is otherwise > the same originator but MUST continue to use the same APP-NAME and > MSGID." I do not think we need to repeat what is already said in RFC 5424. I am not convinced that this text is needed. > Can one SYSLOG message contain many snmp SDEs to convey many SNMP > notifications together? I don't think it is clear in current text. I will add a sentence somewhere that a notification maps to exactly one SYSLOG message. It was not the intention to carry multiple SNMP notifications in a single SYSLOG message. > > > (2)There should be a counterpart to para2, sec7 in syslog-snmp-02 > > > in this doc. > > > > I do not think there is an access control mechanism for SYSLOG so I am > > not sure what you are looking for. Can you elaborate? > > If I understand correctly, para2, sec7 recommends > snmp-syslog-translator should enforce consistent policy with > SNMP. And the similar text should be added to recommends > syslog-snmp-translator should enfore consistent policy with SYSLOG. > IMO, SYSLOG does have its rules to say which host is expected to > receive which part of messages(filters). So, when SYSLOG messages > are converted to SNMP notification, the same rules should apply. I added one sentence and the last bullet in section 10 now reads: o syslogMsgFacility, syslogMsgSeverity, syslogMsgVersion, syslogMsgTimeStamp, syslogMsgHostName, syslogMsgAppName, syslogMsgProcID, syslogMsgMsgID, syslogMsgMsg, syslogMsgFlags, syslogMsgSDParamValue: These objects carry the content of syslog messags and the syslog message oriented security considerations of [RFC5424] apply. In particular, an attacker who gains access to SYSLOG messages via SNMP may use the knowledge gained from SYSLOG messages to compromise a machine or do other damage. It is therefore desirable to configure SNMP access control rules enforcing a consistent security policy for SYSLOG messages. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Wed Apr 8 09:53:48 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F8328C24F for ; Wed, 8 Apr 2009 09:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyNc8KOLVYxn for ; Wed, 8 Apr 2009 09:53:47 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id EB95128C29D for ; Wed, 8 Apr 2009 09:53:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHQ00ASP0JW4B50@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Tue, 07 Apr 2009 15:52:46 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHQ00CKG0JUW400@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Tue, 07 Apr 2009 15:52:44 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 07 Apr 2009 15:52:42 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Tue, 07 Apr 2009 15:52:42 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090406163111.GA21517@elstar.local> References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406163111.GA21517@elstar.local> Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:53:48 -0000 > On Thu, Mar 26, 2009 at 06:34:04PM +0100, Scott O. Bradner wrote: > > > > this starts a WGLC on > > draft-ietf-opsawg-syslog-snmp-02.txt I reviewed again, and found it has addressed my previous concerns. But some new issues I'd like to raise at this point: (1)wrt/ the figure in page 6, there can be many SNMP notification originators, but why not allow for many SYSLOG collectors? (2) information extracted from SNMP notification should be reflected in snmp SDE only or some other places. for example, "origin" SD-ID can refect SNMP notif, which mentioned in sec3.2. What about SYSLOG HEADER, MSGID, for example, represents the type of SNMP notif or the SYSLOG messages, in the latter case, all SYSLOG messages containing snmp SDE should have the same MSGID. (3) How about one SYSLOG message contains multiplex snmp SDEs, is it allowed? nit: 3rd sentence, 1st para, sec2.2: RFCxxxx should be RFC5424. > > and > > draft-ietf-opsawg-syslog-msg-mib-02.txt > > I reviewed again, and found it has addressed my previous concerns. But, there are some concerns wrt/ consistency with syslog-snmp-02: (1)snmp-to-syslog translator is defined in syslog-snmp-02, but no syslog-to-snmp translator definition. (2)There should be a counterpart to para2, sec7 in syslog-snmp-02 in this doc. some nits: (3)sec4, para5: The syslogMsgTable contains one entry for each recorded SYSLOG message. The basic fields of SYSLOG messages are represented in different columns of the conceptual table. Actually, a flag syslogMsgFlags is also in the table, how about: The basic fields of SYSLOG messages are represented in different columns of the conceptual table as well as a flag called syslogMsgFlags. (4) --syslogMsgObjects(1) | +--syslogMsgSDTable(3) | +--syslogMsgSDEntry(1) [syslogMsgIndex, | syslogMsgSDParamIndex <--- comma lacked | syslogMsgSDID, | syslogMsgSDParamName] | +-- Unsigned32 syslogMsgSDParamIndex(1) +-- DisplayString syslogMsgSDID(2) +-- DisplayString syslogMsgSDParamName(3) +-- SnmpAdminString syslogMsgSDParamValue(4) (5)I-D.ietf-syslog-protocol and I-D.ietf-syslog-tc-mib should be substituted with corresponding RFCs. washam From Washam.Fan@huaweisymantec.com Wed Apr 8 19:15:29 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AED3A6B5D for ; Wed, 8 Apr 2009 19:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcgWg6fvkv2Y for ; Wed, 8 Apr 2009 19:15:29 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id F176A3A6AA2 for ; Wed, 8 Apr 2009 19:15:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHT008IVABBME90@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 09 Apr 2009 10:16:25 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHT006E7AB9TE20@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 09 Apr 2009 10:16:23 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 09 Apr 2009 10:16:21 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Thu, 09 Apr 2009 10:16:21 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090408123127.GC1060@elstar.local> References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406163111.GA21517@elstar.local> <20090407121017.GC29263@elstar.local> <20090408123127.GC1060@elstar.local> Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 02:15:30 -0000 > On Wed, Apr 08, 2009 at 05:37:37AM +0200, WashamFan wrote: > > > Still I suggest more text for SYSLOG specific HEADER like this: > > "This specification does > > not mandate particular values for these fields; however, for > > consistency, SYSLOG originators MUST use the same values for APP-NAME, > > PROCID, and MSGID fields for every message that is > > sent, whichever values are chosen. To allow for the possibility > of > > multiple originators per host, the combination of APP-NAME, PROCID, > > and MSGID MUST be unique for each such originator. If an originator > > daemon is restarted, it MAY use a new PROCID for what is otherwise > > the same originator but MUST continue to use the same APP-NAME and > > MSGID." > > I do not think we need to repeat what is already said in RFC 5424. I > am not convinced that this text is needed. Actually, I copy those statements from syslog-sign, and I don't think they appear somewhere in RFC5424. We can take most of these statements for granted except that they imply all messages containing the ssgin SDE have the same MSGID whatever it would be. Does the doc has the same implication as those statements? If yes, then no problem for me. washam From j.schoenwaelder@jacobs-university.de Wed Apr 8 22:49:53 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890C23A6A0C for ; Wed, 8 Apr 2009 22:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcqY7i1H3U-t for ; Wed, 8 Apr 2009 22:49:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2913A3A68A5 for ; Wed, 8 Apr 2009 22:49:51 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 082B8C0019; Thu, 9 Apr 2009 07:50:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ub5lL2iMNYni; Thu, 9 Apr 2009 07:50:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7F5FC0017; Thu, 9 Apr 2009 07:50:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BFD29A6B785; Thu, 9 Apr 2009 07:50:39 +0200 (CEST) Date: Thu, 9 Apr 2009 07:50:39 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090409055039.GB23785@elstar.local> Mail-Followup-To: WashamFan , "opsawg@ietf.org" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <20090406163111.GA21517@elstar.local> <20090407121017.GC29263@elstar.local> <20090408123127.GC1060@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 05:49:53 -0000 On Thu, Apr 09, 2009 at 04:16:21AM +0200, WashamFan wrote: > > On Wed, Apr 08, 2009 at 05:37:37AM +0200, WashamFan wrote: > > > > > Still I suggest more text for SYSLOG specific HEADER like this: > > > "This specification does > > > not mandate particular values for these fields; however, for > > > consistency, SYSLOG originators MUST use the same values for APP-NAME, > > > PROCID, and MSGID fields for every message that is > > > sent, whichever values are chosen. To allow for the possibility > > of > > > multiple originators per host, the combination of APP-NAME, PROCID, > > > and MSGID MUST be unique for each such originator. If an originator > > > daemon is restarted, it MAY use a new PROCID for what is otherwise > > > the same originator but MUST continue to use the same APP-NAME and > > > MSGID." > > > > I do not think we need to repeat what is already said in RFC 5424. I > > am not convinced that this text is needed. > > Actually, I copy those statements from syslog-sign, and I don't think they > appear somewhere in RFC5424. We can take most of these statements for > granted except that they imply all messages containing the ssgin SDE have > the same MSGID whatever it would be. Does the doc has the same implication > as those statements? If yes, then no problem for me. While the sign document perhaps has reasons for these additional requirements to make signatures to work, I do not see a reason why the SNMP mapping should require anything more than what is in RFC 5424. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu Apr 9 09:36:49 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2DC33A67EB for ; Thu, 9 Apr 2009 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocYGFF4C9ZU7 for ; Thu, 9 Apr 2009 09:36:48 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id BA0BF3A69B1 for ; Thu, 9 Apr 2009 09:36:47 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA05.westchester.pa.mail.comcast.net with comcast id dPLp1b0070xGWP855UdsiT; Thu, 09 Apr 2009 16:37:52 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id dUdw1b00D0UQ6dC3YUdweE; Thu, 09 Apr 2009 16:37:56 +0000 From: "David Harrington" To: "'Sharon Chisholm'" , "'Juergen Schoenwaelder'" References: <713043CE8B8E1348AF3C546DBE02C1B41824B2E0@zcarhxm2.corp.nortel.com><20090201133347.GA18098@elstar.local><713043CE8B8E1348AF3C546DBE02C1B418C6CA06@zcarhxm2.corp.nortel.com><20090323135224.GA14442@elstar.local><713043CE8B8E1348AF3C546DBE02C1B418C6CEAD@zcarhxm2.corp.nortel.com><20090323165337.GA15855@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B418EE1A3E@zcarhxm2.corp.nortel.com> Date: Thu, 9 Apr 2009 12:37:55 -0400 Message-ID: <02f701c9b931$88c41e20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmsDih5tWsd6WE4QSa4IHoZbE2QBwITPrlAATV6K8A= In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B418EE1A3E@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Proposed update to syslog Alarm X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:36:49 -0000 Hi, I think my perspective is to either fix it or remove it. As Juergen and I have pointed out, the OID is incomplete without a context. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Sharon Chisholm > Sent: Friday, April 03, 2009 9:00 AM > To: Juergen Schoenwaelder > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Proposed update to syslog Alarm > > Hi > > It is acknowledged that resourceOID does not work in all circumstances > but the idea of leaving it in is that it is understood by the majority > of SNMP users. The URI approach was introduced to cover the cases that > OID could not. So, we are using the SNMP URI approach either way, the > question is whether to also keep the resourceOID. In my view, using > OIDS, which are universally understood, is something a lot of > implementations will want to do so it would be nice to have a standard > way to do that, but I'll go with working group consensus. > > So far I have heard > > Dave H - remove it > Sharon - keep it > Juergen - remove it or align it to other work > > So, if there are no other views I would suggest that we remove it. > > Sharon > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, March 23, 2009 12:54 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Proposed update to syslog Alarm > > On Mon, Mar 23, 2009 at 05:04:41PM +0100, Sharon Chisholm wrote: > > > So, are you OK with leaving all three in the document? > > Once again, resourceOID is broken. If you leave it, you have > to fix it. > My preference would be to either (a) use the SNMP URI scheme or > (b) use the the SNMP to SYSLOG mappings also defined as part of the > OPSAWG working group. If you plan to invent a third solution, > make sure > you have strong arguments; I prefer to reuse existing solutions. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From hongyanfeng@huaweisymantec.com Fri Apr 10 01:43:00 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89FB3A67D9 for ; Fri, 10 Apr 2009 01:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI-ECTWbYEXG for ; Fri, 10 Apr 2009 01:43:00 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 198A13A6AF4 for ; Fri, 10 Apr 2009 01:43:00 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHV00CCRMX7AP40@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Fri, 10 Apr 2009 16:43:57 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHV00FQWMX55O00@hstml02-in.huaweisymantec.com> for opsawg@ietf.org; Fri, 10 Apr 2009 16:43:55 +0800 (CST) Received: from [10.27.154.136] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 10 Apr 2009 16:43:53 +0800 From: fenghongyan To: opsawg@ietf.org Message-id: Date: Fri, 10 Apr 2009 16:43:53 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Subject: [OPSAWG] FW: New Version Notification for draft-feng-syslog-transport-dtls-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 08:43:01 -0000 Hi, A new version is available, please feel free to add any comments or suggestions on it. I-D Submission Tool URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=14380 Filename: draft-feng-syslog-transport-dtls Version: 01 Staging URL: http://www3.ietf.org/proceedings/staging/draft-feng-syslog-transport-dtls-01.txt Title: Transmission of SYSLOG message over DTLS Creation_date: 2009-04-10 WG ID: Indvidual Submission Number_of_pages: 9 Abstract: This document describes a Transport for the Syslog Protocol, that uses the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides authentication and privacy services for SYSLOG applications. This document describes how using DTLS to transport SYSLOG messages makes this protection possible in an interoperable way. This transport is designed to meet the security and operational needs of network administrators, operate in environments where a datagram transport is preferred, and integrates well into existing public keying infrastructures. From cfinss@dial.pipex.com Fri Apr 10 10:46:09 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7833A6A86 for ; Fri, 10 Apr 2009 10:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb4OqiMtTHhu for ; Fri, 10 Apr 2009 10:46:08 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 6307D3A6C22 for ; Fri, 10 Apr 2009 10:45:57 -0700 (PDT) X-Trace: 92735813/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.128/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.128 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FALci30k+vBOA/2dsb2JhbABFgmVJijW9IQeDdAaHRQ X-IronPort-AV: E=Sophos;i="4.40,168,1238972400"; d="scan'208";a="92735813" X-IP-Direction: IN Received: from 1cust128.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.128]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Apr 2009 18:47:04 +0100 Message-ID: <006301c9b9fb$fec4a5c0$0601a8c0@allison> From: "tom.petch" To: , "Scott O. Bradner" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> Date: Fri, 10 Apr 2009 10:21:29 +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 Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 17:46:09 -0000 opsawg-syslog-msg-mib has references to a syslog receiver. This term no longer exists being replaced by collector, relay and transport receiver. From an architectural perspective, an SNMP NO or NR corresponds to originator, relay or collector so the last is perhaps the best fit. Likewise, opsawg-syslog-snmp has syslog receiver, syslog sender and SYSLOG sender application (the last of which contradicts the terminology in syslog-protocol:-). Probably, collector and originator are appropriate. Tom Petch ----- Original Message ----- From: "Scott O. Bradner" To: Sent: Thursday, March 26, 2009 7:34 PM Subject: [OPSAWG] WGLC on syslog/snmp IDs > > this starts a WGLC on > draft-ietf-opsawg-syslog-snmp-02.txt > and > draft-ietf-opsawg-syslog-msg-mib-02.txt > > please send any comments to the list by April 13th > > thanks > > Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From ietfdbh@comcast.net Fri Apr 10 11:41:29 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2DE3A69E2 for ; Fri, 10 Apr 2009 11:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_05=-1.11, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPDJaz-K+fDf for ; Fri, 10 Apr 2009 11:41:28 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 113603A6832 for ; Fri, 10 Apr 2009 11:41:27 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id dtKX1b0070bG4ec54uidQd; Fri, 10 Apr 2009 18:42:37 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id dui21b00C0UQ6dC3Pui2Bz; Fri, 10 Apr 2009 18:42:02 +0000 From: "David Harrington" To: "'tom.petch'" , , "'Scott O. Bradner'" References: <20090326173404.4D209152478F@newdev.eecs.harvard.edu> <006301c9b9fb$fec4a5c0$0601a8c0@allison> Date: Fri, 10 Apr 2009 14:42:36 -0400 Message-ID: <039601c9ba0c$1e408ad0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm6BGaOHKYp19qvSP+Sjte88uVm+wAB3PMg In-Reply-To: <006301c9b9fb$fec4a5c0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 18:41:29 -0000 Hi, FYI. RFC5424 has the terminology that the syslog WG agreed to use. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of tom.petch > Sent: Friday, April 10, 2009 4:21 AM > To: opsawg@ietf.org; Scott O. Bradner > Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs > > opsawg-syslog-msg-mib has references to a syslog receiver. > > This term no longer exists being replaced by collector, relay > and transport > receiver. From an architectural perspective, an SNMP NO or NR > corresponds to > originator, relay or collector so the last is perhaps the best fit. > > Likewise, opsawg-syslog-snmp has syslog receiver, syslog > sender and SYSLOG > sender application (the last of which contradicts the terminology in > syslog-protocol:-). Probably, collector and originator are > appropriate. > > Tom Petch > > > ----- Original Message ----- > From: "Scott O. Bradner" > To: > Sent: Thursday, March 26, 2009 7:34 PM > Subject: [OPSAWG] WGLC on syslog/snmp IDs > > > > > > this starts a WGLC on > > draft-ietf-opsawg-syslog-snmp-02.txt > > and > > draft-ietf-opsawg-syslog-msg-mib-02.txt > > > > please send any comments to the list by April 13th > > > > thanks > > > > Scott > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From Washam.Fan@huaweisymantec.com Sun Apr 12 19:44:26 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B6A3A6CBA for ; Sun, 12 Apr 2009 19:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-1.624, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbIIQQIEFdr3 for ; Sun, 12 Apr 2009 19:44:25 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 1E4033A69F6 for ; Sun, 12 Apr 2009 19:44:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KI0002KRQBNZR20@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Mon, 13 Apr 2009 10:45:24 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KI000K0FQBHLN00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Mon, 13 Apr 2009 10:45:22 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 13 Apr 2009 10:45:17 +0800 From: WashamFan To: WashamFan Message-id: Date: Mon, 13 Apr 2009 10:45:17 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: References: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] FW:New Version Notification for draft-meng-fan-lock-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 02:44:26 -0000 Hi, Anybody interested in this topic or want to review this draft? Or just tell me it is an inappropriate time to consider it? Or the work seems not worthwhile to you? Thanks in advance! washam > Hi, > > This draft defines a MIB to monitor locks via different NM interfaces. > It is used to monitor Netconf locks, Cops-Pr locks, and can be > extended to support new interface locks. draft-ietf-netconf-monitoring > now focus on Netconf locks mainly, IMO. > It is relevant to netconf, cops-pr, mib, and so on, so I think it is > an appropriate place to accommodate this draft. > > washam > > A new version of I-D, draft-meng-fan-lock-mib-01.txt has been > successfuly submitted by Washam Fan and posted to the IETF repository. > > Filename: draft-meng-fan-lock-mib > Revision: 01 > Title: Definitions of Managed Objects for lock via > network management protocols > Creation_date: 2009-04-01 > WG ID: Independent Submission > Number_of_pages: 20 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > It describes managed objects used for monitoring locks on a device, > in paticularly, acquired or released by NETCONF and COPS-PR entities. >