From opsawg-bounces@ietf.org Sun Feb 1 05:34:20 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1393A6852; Sun, 1 Feb 2009 05:34:19 -0800 (PST) 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 BB96D3A687A for ; Sun, 1 Feb 2009 05:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 WVBsSG6srCJE for ; Sun, 1 Feb 2009 05:34:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B290D3A6359 for ; Sun, 1 Feb 2009 05:34:17 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B565FC007D; Sun, 1 Feb 2009 14:33:58 +0100 (CET) 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 kszSTXTI7tOT; Sun, 1 Feb 2009 14:33:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 895DEC0043; Sun, 1 Feb 2009 14:33:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 387E991ED0B; Sun, 1 Feb 2009 14:33:47 +0100 (CET) Date: Sun, 1 Feb 2009 14:33:47 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20090201133347.GA18098@elstar.local> Mail-Followup-To: Sharon Chisholm , opsawg@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41824B2E0@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41824B2E0@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.19 (2009-01-05) 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 Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org On Fri, Jan 30, 2009 at 11:18:04AM -0500, Sharon Chisholm wrote: > Attached is the propose update to the Syslog Alarm draft as a result of > comments received during working group last call. I believe it addresses > all known issues. > > Please let me know if you have any comments or corrections and I can > make any necessary changes before posting this as version -02. - Capitalize the section 1.1 heading or get rid of the heading and make the two sentences part of section 1. - You sometimes use "resource" and sometimes "alarmResource", please pick one an be consistent. - Section 3.6 is confusing - we now have three resource identifiers: (1) resource (or alarmResource) The specification leaves it open what it contains; so this value is really just for humans to read. (2) resourceOID This SD-ID contains an OID, namely the value of the alarmActiveResourceId MIB object. This SD-ID suffers from the problem that it does not carry SNMP context information and is thus ambiguous. (3) resourceURI This is defined to hold an SNMP URI. This solved the missing SNMP context problem of resourceOID but fires back in the sense that it can't carry other URIs. My proposal is to keep (1), delete (2), and to change (3) such that it can carry arbitrary URIs and can appear multiple times. If an alarmActiveResourceId MIB object exists, the value should be reported using the SNMP URI format in an resourceURI SD-ID. - In the example, I find it strange to consider "su root" a resource. For me, the resource raising the alarm is a subsystem of the OS dealing with authorization decisions. Also the message in the message part is not likely to be generated when you have an unauthorizedAccessAttempt. Please make the example more realistic. /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 opsawg-bounces@ietf.org Mon Feb 2 04:40:45 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3C328C154; Mon, 2 Feb 2009 04:40:45 -0800 (PST) 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 A39E328C154 for ; Mon, 2 Feb 2009 04:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 nULweww6c4mY for ; Mon, 2 Feb 2009 04:40:42 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A864C28C0F4 for ; Mon, 2 Feb 2009 04:40:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,365,1231131600"; d="scan'208";a="159893646" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 02 Feb 2009 07:40:22 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2009 07:40:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 13:39:58 +0100 Message-ID: In-Reply-To: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt thread-index: AcmCf+6Dw0EjDHCoReukukGWp0iR7ACspMxg References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> From: "Romascanu, Dan (Dan)" To: "Scott O. Bradner" , Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Answers like - 'I have read the document and I believe it's important enough and good enough to be submitted to the IESG' are also acceptable. As a reminder - the WG is also in WGLC with draft-ietf-opsawg-operations-and-management. We need more input with both documents to know how we proceed. Dan > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Scott O. Bradner > Sent: Friday, January 30, 2009 4:10 AM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] start WGLC > ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt > > > back on Nov 6th we sent out a WGLC on > draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt > > there was no response to that last call that I can find in > the mail list archive (or in my memory) > > we gotta see a bit more interest than that to proceed with > this document. > > So, I'll try again > > this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt > please comment (one way or the other) by Feb 12 > > tnx > > 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 opsawg-bounces@ietf.org Mon Feb 2 05:01:12 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7F03A6B23; Mon, 2 Feb 2009 05:01:12 -0800 (PST) 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 5E9373A6B23 for ; Mon, 2 Feb 2009 05:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 w6gmbRZPR1Wf for ; Mon, 2 Feb 2009 05:01:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 515BE3A68C6 for ; Mon, 2 Feb 2009 05:01:11 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E739CC0082; Mon, 2 Feb 2009 14:00:51 +0100 (CET) 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 PbiFsKL-vH16; Mon, 2 Feb 2009 14:00:46 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19015C0136; Mon, 2 Feb 2009 14:00:45 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id C300B95AE45; Mon, 2 Feb 2009 14:00:44 +0100 (CET) Date: Mon, 2 Feb 2009 14:00:44 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090202130044.GC3897@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Scott O. Bradner" , opsawg@ietf.org References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org On Mon, Feb 02, 2009 at 01:39:58PM +0100, Romascanu, Dan (Dan) wrote: > Answers like - 'I have read the document and I believe it's important > enough and good enough to be submitted to the IESG' are also acceptable. I have read the revised version and I still have a meta issue with the following statement: : This memo is the first in a set of three related and (logically) : ordered specifications: : : 1. SMI Base Datatypes [RFC2578] in XSD : 2. SMI MIB Structure [RFC2578] in XSD : 3. SNMP Textual Conventions [RFC2579] in XSD We have a discussion at the IETF in Dublin the scope of this work and I think the chairs got a task to sort this out, which as far as I can tell did not happen. For some details, please see the meeting minutes. Since I have not seen any documents for items 2. and 3., I am somewhat unsure that the scope defined in this document is correct and that it should be there in the first place, especially since there are no working documents nor is it clear that the charter covers 2. and 3. /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 opsawg-bounces@ietf.org Mon Feb 2 09:03:58 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5593A6BB9; Mon, 2 Feb 2009 09:03:58 -0800 (PST) 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 362FC3A6973 for ; Mon, 2 Feb 2009 09:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.072 X-Spam-Level: X-Spam-Status: No, score=-0.072 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 NlfshzgUEVvN for ; Mon, 2 Feb 2009 09:03:56 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 1FEA93A6A4B for ; Mon, 2 Feb 2009 09:03:55 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LU2Ct-0005ST-QX; Mon, 02 Feb 2009 18:03:35 +0100 Message-ID: <24B02350414E4C5AA36BDA3CF7DE291D@BertLaptop> From: "Bert Wijnen \(IETF\)" To: , "Scott O. Bradner" References: <20090125164013.802B5129CDC6@newdev.eecs.harvard.edu> In-Reply-To: <20090125164013.802B5129CDC6@newdev.eecs.harvard.edu> Date: Mon, 2 Feb 2009 18:03:13 +0100 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management 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: , Content-Type: multipart/mixed; boundary="===============0308862514==" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org This is a multi-part message in MIME format. --===============0308862514== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0452_01C98560.844E5310" This is a multi-part message in MIME format. ------=_NextPart_000_0452_01C98560.844E5310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had reviewed earlier versions of this document a few times. Last time was in 2007 (possibly early 2008). I believe the document has improved A LOT since those revuiews. Thanks for the effort that must have gone into that. I still wonder if the document is not too long. That may deter potential new readers. At the other hand, I also would not be able to tell you = what=20 to remove or how to organize. I sympathize a lot with the comments that Juergen Schoenwaelder made (a week ago or so). At the other hand... maybe we should just go ahead and publish and see if the intended users will find this helpful or not.=20 Bert ----- Original Message -----=20 From: Scott O. Bradner=20 To: opsawg@ietf.org=20 Sent: Sunday, January 25, 2009 5:40 PM Subject: [OPSAWG] (final) WGLC on = draft-ietf-opsawg-operations-and-management This is a (hopefully final) WGLC for = draft-ietf-opsawg-operations-and-management there was not enough respose to the last one back in October please let the list know what you think of the draft thanks Scott & Ted _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_0452_01C98560.844E5310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I had reviewed earlier versions of this document a = few=20 times.
Last time was in 2007 (possibly early = 2008).
 
I believe the document has improved A LOT since = those=20 revuiews.
Thanks for the effort that must have gone into=20 that.
 
I still wonder if the document is not too long. That = may deter=20 potential
new readers. At the other hand, I also would not be = able to=20 tell you what
to remove or how to organize. I sympathize a lot = with the=20 comments that
Juergen Schoenwaelder made (a week ago or = so).
 
At the other hand... maybe we should just go ahead = and publish=20 and see
if the intended users will find this helpful or not. =
 
Bert
----- Original Message -----
From:=20 Scott O. = Bradner=20
Sent: Sunday, January 25, 2009 = 5:40=20 PM
Subject: [OPSAWG] (final) WGLC = on=20 draft-ietf-opsawg-operations-and-management


This is a (hopefully final) WGLC for=20 draft-ietf-opsawg-operations-and-management

there was not = enough=20 respose to the last one back in October

please let the list = know what=20 you think of the draft

thanks

Scott &=20 Ted

_______________________________________________
OPSAWG = mailing=20 list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg
------=_NextPart_000_0452_01C98560.844E5310-- --===============0308862514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============0308862514==-- From opsawg-bounces@ietf.org Mon Feb 2 09:41:53 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B951D3A692A; Mon, 2 Feb 2009 09:41:53 -0800 (PST) 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 269B43A67F4 for ; Mon, 2 Feb 2009 09:41:53 -0800 (PST) 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=[AWL=0.000, 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 vVvXTxgrvNyx for ; Mon, 2 Feb 2009 09:41:52 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id A12FF3A6929 for ; Mon, 2 Feb 2009 09:41:28 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n12Hf8hP008149 for ; Mon, 2 Feb 2009 12:41:08 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n12Hf8Sk008131; Mon, 2 Feb 2009 12:41:08 -0500 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 2 Feb 2009 12:41:08 -0500 From: "Natale, Bob" To: "j.schoenwaelder@jacobs-university.de" Date: Mon, 2 Feb 2009 12:41:06 -0500 Thread-Topic: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt Thread-Index: AcmFNkku0ATXcJWcTxqz/UeNTnZgzQAJkt2g Message-ID: <17969D855F28964C88D177D45B6CDF11F2296C61@IMCMBX2.MITRE.ORG> References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> <20090202130044.GC3897@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090202130044.GC3897@elstar.iuhb02.iu-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Hi Juergen, I have no problem removing the text that gives rise to your "meta-issue" as part of a revision for transmittal to the IESG, but I don't think it should require another round of WGLC...? We had specific substantive inputs from a fair number of people during earlier drafts -- as is to be desired -- and all of those inputs have been incorporated or otherwise adjudicated, to the best of my knowledge. Cheers, BobN -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Monday, February 02, 2009 8:01 AM To: Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt On Mon, Feb 02, 2009 at 01:39:58PM +0100, Romascanu, Dan (Dan) wrote: > Answers like - 'I have read the document and I believe it's important > enough and good enough to be submitted to the IESG' are also acceptable. I have read the revised version and I still have a meta issue with the following statement: : This memo is the first in a set of three related and (logically) : ordered specifications: : : 1. SMI Base Datatypes [RFC2578] in XSD : 2. SMI MIB Structure [RFC2578] in XSD : 3. SNMP Textual Conventions [RFC2579] in XSD We have a discussion at the IETF in Dublin the scope of this work and I think the chairs got a task to sort this out, which as far as I can tell did not happen. For some details, please see the meeting minutes. Since I have not seen any documents for items 2. and 3., I am somewhat unsure that the scope defined in this document is correct and that it should be there in the first place, especially since there are no working documents nor is it clear that the charter covers 2. and 3. /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 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Feb 3 09:52:05 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B229E28C172; Tue, 3 Feb 2009 09:52:05 -0800 (PST) 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 6B95728C16A for ; Tue, 3 Feb 2009 09:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8rqu3Ke0kx68 for ; Tue, 3 Feb 2009 09:52:03 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id E7B9028C164 for ; Tue, 3 Feb 2009 09:52:02 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so815129qwe.31 for ; Tue, 03 Feb 2009 09:51:42 -0800 (PST) Received: by 10.214.215.19 with SMTP id n19mr8792206qag.59.1233683500487; Tue, 03 Feb 2009 09:51:40 -0800 (PST) Received: from ?192.168.1.205? (pool-71-168-120-18.cncdnh.fios.myfairpoint.net [71.168.120.18]) by mx.google.com with ESMTPS id 2sm3191857qwi.40.2009.02.03.09.51.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Feb 2009 09:51:40 -0800 (PST) Message-ID: <4988842C.7080300@ieee.org> Date: Tue, 03 Feb 2009 12:51:40 -0500 From: Mark Ellison Organization: Ellison Software Consulting, Inc. User-Agent: Thunderbird 2.0b2 (X11/20070116) MIME-Version: 1.0 To: sob@harvard.edu, opsawg@ietf.org, "Romascanu, Dan (Dan)" References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> In-Reply-To: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> Subject: Re: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ellison@ieee.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Hi, I have participated in reviews of the draft-ietf-opsawg-smi-datatypes-in-xsd document. I have also been involved with a few SNMP/MIB projects that transformed data between SMIv2, XML and Java representations. I think it is worthwhile for the IETF to provide a standard schema representation of the SMIv2 data types for XML and recommend this draft be submitted for publication as an RFC. Regards, Mark http://ellisonsoftware.com/company/principal-consultant/ On 01/29/2009 09:10 PM, Scott O. Bradner wrote: > back on Nov 6th we sent out a WGLC on > draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt > > there was no response to that last call that I can > find in the mail list archive (or in my memory) > > we gotta see a bit more interest than that to proceed > with this document. > > So, I'll try again > > this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt > please comment (one way or the other) by Feb 12 > > tnx > > 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 bertietf@bwijnen.net Wed Feb 4 01:57:32 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 1DF693A6821 for ; Wed, 4 Feb 2009 01:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.851 X-Spam-Level: X-Spam-Status: No, score=0.851 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 3oYz8FtVqMx8 for ; Wed, 4 Feb 2009 01:57:31 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id F04CD3A67AD for ; Wed, 4 Feb 2009 01:57:29 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LUeVI-0000Dl-Lr for opsawg@ietf.org; Wed, 04 Feb 2009 10:57:08 +0100 Message-ID: <0D6B0A42F7EE4DA1B50DC45C2990A849@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> In-Reply-To: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> Date: Wed, 4 Feb 2009 10:56:35 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0943_01C986B7.3F37D2D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.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: Wed, 04 Feb 2009 09:57:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0943_01C986B7.3F37D2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My comments: - page 7, section 4 - speaks about opague. I think you mean opaque (with a Q) You may also want to make an explicit statement that those are the = datatype names as ytou specify them in XSD. I first though they were the = datatypes as specified in SMIv2. - Opague (with a G) is again used in the 1st para of sect 5.3 and=20 in the first bullet on page 12 and also 3rd bullet. I share/support Juergen Shoenwaelder's comment w.r.t. the discussion = about 3 documents in a document set. Where, how is that otehr work scheduled/planned? Other than that, this document seems fine. Bert ----- Original Message -----=20 From: Scott O. Bradner=20 To: opsawg@ietf.org=20 Sent: Friday, January 30, 2009 3:10 AM Subject: Re: [OPSAWG] start WGLC = ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt back on Nov 6th we sent out a WGLC on=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt there was no response to that last call that I can=20 find in the mail list archive (or in my memory) we gotta see a bit more interest than that to proceed with this document. =20 So, I'll try again=20 this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt please comment (one way or the other) by Feb 12 tnx Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_0943_01C986B7.3F37D2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My comments:
 
- page 7, section 4
  - speaks about opague. I think you mean = opaque (with a=20 Q)
 
  You may also want to make an explicit = statement that=20 those are the datatype
  names as ytou specify them in XSD. I first = though they=20 were the datatypes
  as specified in SMIv2.
 
 
- Opague (with a G) is again used in the 1st para of = sect 5.3=20 and 
   in the first bullet on page 12 and also = 3rd=20 bullet.
 
I share/support Juergen Shoenwaelder's comment = w.r.t. the=20 discussion about 3 documents
in a document set. Where, how is that otehr work=20 scheduled/planned?
 
Other than that, this document seems = fine.
 
Bert
----- Original Message -----
From:=20 Scott O. = Bradner=20
Sent: Friday, January 30, 2009 = 3:10=20 AM
Subject: Re: [OPSAWG] start = WGLC=20 ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt


back on Nov 6th we sent out a = WGLC on=20
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

there was no = response=20 to that last call that I can
find in the mail list archive (or in = my=20 memory)

we gotta see a bit more interest than that to = proceed
with=20 this document. 

So, I'll try again

this is a WGLC = for=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt
please comment (one = way or=20 the other) by Feb=20 = 12

tnx

Scott
___________________________________________= ____
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg
------=_NextPart_000_0943_01C986B7.3F37D2D0-- From RNATALE@mitre.org Wed Feb 4 05:18:04 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 C8CF428C236 for ; Wed, 4 Feb 2009 05:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3mQmUOwaCjqC for ; Wed, 4 Feb 2009 05:17:58 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 49E4E28C114 for ; Wed, 4 Feb 2009 05:17:58 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n14DHblw004256 for ; Wed, 4 Feb 2009 08:17:37 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n14DHb5I004247; Wed, 4 Feb 2009 08:17:37 -0500 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 4 Feb 2009 08:17:37 -0500 From: "Natale, Bob" To: "Bert Wijnen (IETF)" Date: Wed, 4 Feb 2009 08:17:35 -0500 Thread-Topic: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt Thread-Index: AcmGrvaD3XLdpr7sRY2f3vQ7vL18rwAGpE6A Message-ID: <17969D855F28964C88D177D45B6CDF11F22974C5@IMCMBX2.MITRE.ORG> References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> <0D6B0A42F7EE4DA1B50DC45C2990A849@BertLaptop> In-Reply-To: <0D6B0A42F7EE4DA1B50DC45C2990A849@BertLaptop> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_17969D855F28964C88D177D45B6CDF11F22974C5IMCMBX2MITREORG_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.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: Wed, 04 Feb 2009 13:18:04 -0000 --_000_17969D855F28964C88D177D45B6CDF11F22974C5IMCMBX2MITREORG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bert, Thanks for your comments and assessment. - The misspellings of "opaque" (with a "g") have been corrected. - The use of "datatypes" in the file name and title was, in fact, intended = to refer to "SMI datatypes" as implied by the general usage in RFC 2578, Se= c. 7.1, "Mapping of the Syntax Clause", to wit: "The SYNTAX clause, which must be present, defines the abstract data struct= ure corresponding to that object. The data structure must be one of the fo= llowing: a base type, the BITS construct, or a textual convention. (SEQUEN= CE OF and SEQUENCE are also possible for conceptual tables, see section 7.1= .12). The base types are those defined in the ObjectSyntax CHOICE. A text= ual convention is a newly-defined type defined as a sub-type of a base type= [3]." So, "datatypes" is used a bit loosely for "base types"...would you prefer t= hat the latter term be used? (The document text currently makes it clear t= hat it deals only with expressing the base types of RFC 2578 in XSD.) - Yes, the text that Juergen questioned is being removed (also had helpful = guidance from David Harrington on this point), so that this "base types" do= cument stands alone. Please confirm or clarify the second point...I will have the -05 version, r= eflecting final mods based on this last call round, ready immediately after= expiration of the last call period (12-Feb-09). Cheers, BobN From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Bert Wijnen (IETF) Sent: Wednesday, February 04, 2009 4:57 AM To: opsawg@ietf.org Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-0= 4.txt My comments: - page 7, section 4 - speaks about opague. I think you mean opaque (with a Q) You may also want to make an explicit statement that those are the dataty= pe names as ytou specify them in XSD. I first though they were the datatypes as specified in SMIv2. - Opague (with a G) is again used in the 1st para of sect 5.3 and in the first bullet on page 12 and also 3rd bullet. I share/support Juergen Shoenwaelder's comment w.r.t. the discussion about = 3 documents in a document set. Where, how is that otehr work scheduled/planned? Other than that, this document seems fine. Bert ----- Original Message ----- From: Scott O. Bradner To: opsawg@ietf.org Sent: Friday, January 30, 2009 3:10 AM Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-0= 4.txt back on Nov 6th we sent out a WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt there was no response to that last call that I can find in the mail list archive (or in my memory) we gotta see a bit more interest than that to proceed with this document. So, I'll try again this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt please comment (one way or the other) by Feb 12 tnx Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_17969D855F28964C88D177D45B6CDF11F22974C5IMCMBX2MITREORG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bert,

 

Thanks for your comments and assessment.

 

- The misspellings of “opaque” (with a “g&#= 8221;) have been corrected.

 

- The use of “datatypes” in the file name and tit= le was, in fact, intended to refer to “SMI datatypes” as implied b= y the general usage in RFC 2578, Sec. 7.1, “Mapping of the Syntax Claus= e”, to wit:

 

“The SYNTAX clause, which must be present, defines the abstract data structure corresponding to that object.  The data struct= ure must be one of the following: a base type, the BITS construct, or a textual= convention.  (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, see sect= ion 7.1.12).  The base types are those defined in the ObjectSyntax CHOICE.  A textual convention is a newly-defined type defined as a sub-type of a base type [3].”

 

So, “datatypes” is used a bit loosely for “= base types”…would you prefer that the latter term be used?  (Th= e document text currently makes it clear that it deals only with expressing t= he base types of RFC 2578 in XSD.)

 

- Yes, the text that Juergen questioned is being removed (als= o had helpful guidance from David Harrington on this point), so that this = 220;base types” document stands alone.

 

Please confirm or clarify the second point…I will have = the -05 version, reflecting final mods based on this last call round, ready imm= ediately after expiration of the last call period (12-Feb-09).

 

Cheers,

BobN

 

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF)
Sent: Wednesday, February 04, 2009 4:57 AM
To: opsawg@ietf.org
Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-i= n-xsd-04.txt

 

My comments:

 

- page 7, section 4

  - speaks about opague. I think you mean opaque (with a Q)=

 

  You may also want to make an explicit statement that those are the datatype=

  names as ytou specify them in XSD. I first though they were the datatypes

  as specified in SMIv2.

 

 

- Opague (with a G) is again used in the 1st para of sect 5.3 and 

   in the first bullet on page 12 and also 3rd bullet.=

 

I share/support Juergen Shoenwaelder's comment w.r.t. the discussion about 3 documents

in a document set. Where, how is that otehr work scheduled/planned?<= /o:p>

 

Other than that, this document seems fine.

 

Bert

----- Original Message ----- <= /span>

Sent: Friday, January 30, 2009 3:10 AM

Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

 


back on Nov 6th we sent out a WGLC on
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

there was no response to that last call that I can
find in the mail list archive (or in my memory)

we gotta see a bit more interest than that to proceed
with this document. 

So, I'll try again

this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt
please comment (one way or the other) by Feb 12

tnx

Scott
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.o= rg/mailman/listinfo/opsawg

--_000_17969D855F28964C88D177D45B6CDF11F22974C5IMCMBX2MITREORG_-- From mark@ellisonsoftware.com Wed Feb 4 05:57: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 8327C28C1B0 for ; Wed, 4 Feb 2009 05:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HGFc243FlmyD for ; Wed, 4 Feb 2009 05:57:15 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 788983A68B2 for ; Wed, 4 Feb 2009 05:57:15 -0800 (PST) Received: by qyk4 with SMTP id 4so3344355qyk.13 for ; Wed, 04 Feb 2009 05:56:54 -0800 (PST) Received: by 10.214.217.12 with SMTP id p12mr9329477qag.303.1233755812763; Wed, 04 Feb 2009 05:56:52 -0800 (PST) Received: from ?192.168.1.205? (pool-71-168-120-18.cncdnh.fios.myfairpoint.net [71.168.120.18]) by mx.google.com with ESMTPS id 2sm2365100qwi.50.2009.02.04.05.56.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Feb 2009 05:56:52 -0800 (PST) Message-ID: <49899EA6.1090106@ieee.org> Date: Wed, 04 Feb 2009 08:56:54 -0500 From: Mark Ellison Organization: Ellison Software Consulting, Inc. User-Agent: Thunderbird 2.0b2 (X11/20070116) MIME-Version: 1.0 To: sob@harvard.edu, opsawg@ietf.org, "Romascanu, Dan (Dan)" References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> In-Reply-To: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ellison@ieee.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 13:57:16 -0000 Hi, I have participated in reviews of the draft-ietf-opsawg-smi-datatypes-in-xsd document. I have also been involved with a few SNMP/MIB projects that transformed data between SMIv2, XML and Java representations. I think it is worthwhile for the IETF to provide a standard schema representation of the SMIv2 data types for XML and recommend this draft be submitted for publication as an RFC. This document represents a good start towards standardizing the representation of management information defined in SMIv2 for XML document driven applicaitons and I look forward with interest to the MIB Structure and TC documents. Regards, Mark http://ellisonsoftware.com/company/principal-consultant/ On 01/29/2009 09:10 PM, Scott O. Bradner wrote: > back on Nov 6th we sent out a WGLC on > draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt > > there was no response to that last call that I can > find in the mail list archive (or in my memory) > > we gotta see a bit more interest than that to proceed > with this document. > > So, I'll try again > > this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt > please comment (one way or the other) by Feb 12 > > tnx > > Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From RNATALE@mitre.org Wed Feb 4 08:50: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 BF5E53A69F6 for ; Wed, 4 Feb 2009 08:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6XI6eo8AAU0n for ; Wed, 4 Feb 2009 08:50:37 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 861CF3A689D for ; Wed, 4 Feb 2009 08:50:37 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n14GoH0D025256 for ; Wed, 4 Feb 2009 11:50:17 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n14GoHsK025245; Wed, 4 Feb 2009 11:50:17 -0500 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 4 Feb 2009 11:50:17 -0500 From: "Natale, Bob" To: Bert Wijnen Date: Wed, 4 Feb 2009 11:50:16 -0500 Thread-Topic: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt Thread-Index: AcmG5ytXOYY2KruRRPm0rnyEfFJ8YQAASiGA Message-ID: <17969D855F28964C88D177D45B6CDF11F2297699@IMCMBX2.MITRE.ORG> References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> <0D6B0A42F7EE4DA1B50DC45C2990A849@BertLaptop> <17969D855F28964C88D177D45B6CDF11F22974C5@IMCMBX2.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_17969D855F28964C88D177D45B6CDF11F2297699IMCMBX2MITREORG_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.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: Wed, 04 Feb 2009 16:50:48 -0000 --_000_17969D855F28964C88D177D45B6CDF11F2297699IMCMBX2MITREORG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bert, Thanks...ok, I see now how to fix the source of the confusion around the te= xt your cited in Sec. 4 - more clarity about which side of the mapping is b= eing referred to. Will do that and also the full check for the implications of resolving refe= rences to "the other two documents" throughout in the update resulting from= this last call round of comments. Cheers, BobN From: Bert Wijnen [mailto:bwijnen@bwijnen.net] Sent: Wednesday, February 04, 2009 11:39 AM To: Natale, Bob Cc: opsawg@ietf.org Subject: Re: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-= 04.txt W.r.t. my second point, section 4 states: This document concerns only the SMI base datatypes -- i.e., the eleven "ObjectSyntax" datatypes defined in RFC2578. These datatypes -- via tag values defined in the SMI to identify them in varbinds -- constrain values carried "on-the-wire" in SNMP PDUs between SNMP management applications and SNMP agents: And then after that colon, it lists the names of the dtaatypes as you defin= e them in sect 4, namely the names used in teh XSD. If they refer to SMI datatype, then I would have expected OBJECT IDENTIFIER= instead of ObjectIdentifier and OCTET STRING instead of OctetString. Not a big deal, but it had me put on the wrong leg at first. By the way, in teh IANA considerations there is also text and URIs w.r.t. "other 2 documents" in the "set of documents". Bert ----- Original Message ----- From: Natale, Bob To: Bert Wijnen (IETF) Cc: opsawg@ietf.org Sent: Wednesday, February 04, 2009 2:17 PM Subject: RE: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-= 04.txt Hi Bert, Thanks for your comments and assessment. - The misspellings of "opaque" (with a "g") have been corrected. - The use of "datatypes" in the file name and title was, in fact, intended = to refer to "SMI datatypes" as implied by the general usage in RFC 2578, Se= c. 7.1, "Mapping of the Syntax Clause", to wit: "The SYNTAX clause, which must be present, defines the abstract data struct= ure corresponding to that object. The data structure must be one of the fo= llowing: a base type, the BITS construct, or a textual convention. (SEQUEN= CE OF and SEQUENCE are also possible for conceptual tables, see section 7.1= .12). The base types are those defined in the ObjectSyntax CHOICE. A text= ual convention is a newly-defined type defined as a sub-type of a base type= [3]." So, "datatypes" is used a bit loosely for "base types"...would you prefer t= hat the latter term be used? (The document text currently makes it clear t= hat it deals only with expressing the base types of RFC 2578 in XSD.) - Yes, the text that Juergen questioned is being removed (also had helpful = guidance from David Harrington on this point), so that this "base types" do= cument stands alone. Please confirm or clarify the second point...I will have the -05 version, r= eflecting final mods based on this last call round, ready immediately after= expiration of the last call period (12-Feb-09). Cheers, BobN From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Bert Wijnen (IETF) Sent: Wednesday, February 04, 2009 4:57 AM To: opsawg@ietf.org Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-0= 4.txt My comments: - page 7, section 4 - speaks about opague. I think you mean opaque (with a Q) You may also want to make an explicit statement that those are the dataty= pe names as ytou specify them in XSD. I first though they were the datatypes as specified in SMIv2. - Opague (with a G) is again used in the 1st para of sect 5.3 and in the first bullet on page 12 and also 3rd bullet. I share/support Juergen Shoenwaelder's comment w.r.t. the discussion about = 3 documents in a document set. Where, how is that otehr work scheduled/planned? Other than that, this document seems fine. Bert ----- Original Message ----- From: Scott O. Bradner To: opsawg@ietf.org Sent: Friday, January 30, 2009 3:10 AM Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-0= 4.txt back on Nov 6th we sent out a WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt there was no response to that last call that I can find in the mail list archive (or in my memory) we gotta see a bit more interest than that to proceed with this document. So, I'll try again this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt please comment (one way or the other) by Feb 12 tnx Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_17969D855F28964C88D177D45B6CDF11F2297699IMCMBX2MITREORG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bert,

 

Thanks…ok, I see now how to fix the source of the confu= sion around the text your cited in Sec. 4 – more clarity about which side = of the mapping is being referred to.

 

Will do that and also the full check for the implications of resolving references to “the other two documents” throughout in= the update resulting from this last call round of comments.

 

Cheers,

BobN

 

From: Bert Wijnen [mailto:bwijnen@bwijnen.net= ]
Sent: Wednesday, February 04, 2009 11:39 AM
To: Natale, Bob
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

 

W.r.t. my second point, section 4 states:

 

   This document concerns only the SMI base datatypes -- i.e., the
   eleven "ObjectSyntax" datatypes defined in RFC2578.  These datatypes
   -- via tag values defined in the SMI to identify them in varbi= nds --
   constrain values carried "on-the-wire" in SNMP PDUs between SNMP
   management applications and SNMP agents:

 

And then after that colon, it lists the names of the dtaatypes as you define th= em in sect 4, namely

the names used in teh XSD.

 

If they refer to SMI datatype, then I would have expected OBJECT IDENTIFIER instead of

ObjectIdentifier and OCTET STRING instead of OctetString.

 

Not a big deal, but it had me put on the wrong leg at first.<= /p>

 

By the way, in teh IANA considerations there is also text and URIs w.r.t.

"other 2 documents" in the "set of documents".

 

Bert

----- Original Message ----- <= /span>

Sent: Wednesday, February 04, 2009 2:17 PM

Subject: RE: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

 

Hi Bert,=

 

Thanks for your comments a= nd assessment.

 

- The misspellings of “opaque” (with a “g”) have been corrected.

 

- The use of “datatypes” in the file name and title was, in fact, intended t= o refer to “SMI datatypes” as implied by the general usage in RFC 2578, Sec. 7.1, “Mapping of the Syntax Clause”, to wit:

 

“The SYNTAX clause, which must be present, defines the abstract data structure corresponding to that object.  The data structure must be one of the following: a base type, the BITS construct, or a textual convention.  (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, see section 7.1.12). = ; The base types are those defined in the ObjectSyntax CHOICE.  A textua= l convention is a newly-defined type defined as a sub-type of a base type [3].”

 

So, “datatypes”= ; is used a bit loosely for “base types”…would you prefer that= the latter term be used?  (The document text currently makes it clear that= it deals only with expressing the base types of RFC 2578 in XSD.)

 

- Yes, the text that Juerg= en questioned is being removed (also had helpful guidance from David Harringto= n on this point), so that this “base types” document stands alone.

 

Please confirm or clarify = the second point…I will have the -05 version, reflecting final mods based= on this last call round, ready immediately after expiration of the last call period (12-Feb-09).

 

Cheers,<= /p>

BobN

 

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF)
Sent: Wednesday, February 04, 2009 4:57 AM
To: opsawg@ietf.org
Subject: Re: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

 

My comments:

 

- page 7, section 4

  - speaks about opague. I think you mean opaque (with a Q)=

 

  You may also want to make an explicit statement that those are the datatype=

  names as ytou specify them in XSD. I first though they were the datatypes

  as specified in SMIv2.

 

 

- Opague (with a G) is again used in the 1st para of sect 5.3 and 

   in the first bullet on page 12 and also 3rd bullet.=

 

I share/support Juergen Shoenwaelder's comment w.r.t. the discussion about 3 documents

in a document set. Where, how is that otehr work scheduled/planned?

 

Other than that, this document seems fine.

 

Bert

----- Original Message ----- <= /span>

Sent: Friday, January 30, 2009 3:10 AM

Subject: Re: [OPSAWG] start WGLC ondraft-i= etf-opsawg-smi-datatypes-in-xsd-04.txt

 


back on Nov 6th we sent out a WGLC on
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

there was no response to that last call that I can
find in the mail list archive (or in my memory)

we gotta see a bit more interest than that to proceed
with this document. 

So, I'll try again

this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt
please comment (one way or the other) by Feb 12

tnx

Scott
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.o= rg/mailman/listinfo/opsawg

--_000_17969D855F28964C88D177D45B6CDF11F2297699IMCMBX2MITREORG_-- From m_ersue@yahoo.de Wed Feb 4 09:37:59 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 57C483A6B42 for ; Wed, 4 Feb 2009 09:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bYUFea+2DiKT for ; Wed, 4 Feb 2009 09:37:58 -0800 (PST) Received: from web24502.mail.ird.yahoo.com (web24502.mail.ird.yahoo.com [87.248.114.229]) by core3.amsl.com (Postfix) with SMTP id 4785E3A6B55 for ; Wed, 4 Feb 2009 09:37:58 -0800 (PST) Received: (qmail 57666 invoked by uid 60001); 4 Feb 2009 17:37:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=uUblqbURgI2iuoorpbLzqsj6Ho1Iaq1EDdLtMdDoz2491ICGiH7+nYNM1J/4iB9JQf7Ia0yfJOL1htoQv5IDoh09wEo4A01qAhWCoAy3je//bJHdbdYiI/kKTWkYxxZUs89dyfT70WDO4F3nINNmtgqDc2CoVIV/igZ5zhWutGE=; X-YMail-OSG: ERR:encrypt:no_context Received: from [217.115.75.230] by web24502.mail.ird.yahoo.com via HTTP; Wed, 04 Feb 2009 17:37:37 GMT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 Date: Wed, 4 Feb 2009 17:37:37 +0000 (GMT) From: Mehmet Ersue To: sob@harvard.edu, Dan Romascanu , Opsawg MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-850022316-1233769057=:57293" Message-ID: <724340.57293.qm@web24502.mail.ird.yahoo.com> Cc: RNATALE@mitre.org Subject: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.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: Wed, 04 Feb 2009 17:37:59 -0000 --0-850022316-1233769057=:57293 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI reviewed this document. One small XSD issue we solved offline.= =0A=0AI think the document is valuable to provide a standard schema =0Arepr= esentation of the SMIv2 data types for XML.=0A=0AI would like to see this d= ocument as an RFC to facilitate the usage =0Afor XML-based applications.=0A= =0AMehmet=0A=0A=0A --0-850022316-1233769057=:57293 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

I reviewed this document. One small XSD issue we solved = offline.

I think the document is valuable to provide a standard sche= ma
representation of the SMIv2 data types for XML.

I would like = to see this document as an RFC to facilitate the usage
for XML-based ap= plications.

Mehmet
 


=0A=0A=0A <= /body> --0-850022316-1233769057=:57293-- From mehmet.ersue@nsn.com Wed Feb 4 09:35:36 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 989A13A6C71 for ; Wed, 4 Feb 2009 09:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.378, 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 Kb97nV1uN2X7 for ; Wed, 4 Feb 2009 09:35:35 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 92CCF3A6B42 for ; Wed, 4 Feb 2009 09:35:35 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n14HZ9sM003187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Feb 2009 18:35:09 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n14HZ8Hr007135; Wed, 4 Feb 2009 18:35:08 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 18:35:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Feb 2009 18:35:06 +0100 Message-ID: In-Reply-To: <49899EA6.1090106@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt Thread-Index: AcmG0OyoEcUBGS7mTiGwC3dID0d1FQAG+z6g References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> <49899EA6.1090106@ieee.org> From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 04 Feb 2009 17:35:08.0749 (UTC) FILETIME=[ECA737D0:01C986EE] X-Mailman-Approved-At: Wed, 04 Feb 2009 09:39:48 -0800 Cc: RNATALE@mitre.org Subject: [OPSAWG] start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.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: Wed, 04 Feb 2009 17:35:36 -0000 Hi, I reviewed this document. One small XSD issue we solved offline. I think the document is valuable to provide a standard schema=20 representation of the SMIv2 data types for XML. I would like to see this document as an RFC to facilitate the usage=20 for XML-based applications. Mehmet =20 From adrian@olddog.co.uk Wed Feb 4 11:56: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 CC8063A6A70 for ; Wed, 4 Feb 2009 11:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 dy-9GuxT50sc for ; Wed, 4 Feb 2009 11:56:04 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id D4AAC3A693B for ; Wed, 4 Feb 2009 11:56:02 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n14JtFot004740; Wed, 4 Feb 2009 19:55:15 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n14JtDJr004730; Wed, 4 Feb 2009 19:55:13 GMT Message-ID: <5C8D68E9DDC2439B82F3CC0591A54F05@your029b8cecfe> From: "Adrian Farrel" To: References: Date: Wed, 4 Feb 2009 19:54:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Wed, 04 Feb 2009 11:59:19 -0800 Cc: David B Harrington , tseely5@gmail.com Subject: Re: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 19:56:09 -0000 Hi, Dan asked me to have a look at this which I do primarily with a routing area view on the world. I'm sorry that I haven't been following this I-D very closely and apologise if you have already discussed and reached conclusion on some of the points I make. I am largely supportive of this work (see draft-ietf-pce-manageability-requirements-06.txt), but I do have some issues. I would be comforted to know that the I-D had had extensive review from within the Ops Area without relying just on my comments! I would also like to understand how the recommendations parts of the draft will be interpreted by the Ops ADs as they perform IESG review of I-Ds from other areas. Depending on the answer (which I would like to see encapsulated in the document!) I might have other harsher comments about the content. More details below. Cheers, Adrian === Title is... Guidelines for Considering Operations and Management of New Protocols ...but the Abstract immediately includes... New protocols or protocol extensions === Obviously needs the new IPR boilerplate. === Abstract line 3 s/protocol/protocols/ === I am somewhat worried by "recommend appropriate standard management protocols ... to address the relevant operations and management needs." I understand the theory behind this guidance in terms of making equipment that will interwork with management systems, but I question its practicality given the vast array of management protocols available. And actually, I am not sure that this has a direct impact on the success of or development of a protocol. The introduction says that this "is similar to a WG considering which security threats are relevant to their protocol, and then recommending appropriate standard security protocols to mitigate the relevant threats." I dispute this. The security considerations normally make modifications to the protocol under development to make it secure, or mandate security features in other protocols that the protocol under development uses. But where there is a need for an external protocol, this is not usually mandated. For example, where key exchange is needed the text will usually say something like "may use some form of secure key exchange protocol (such as the Internet Key Exchange protocol v2 (IKE) [RFC4306]." This is far looser than a recommendation of a specific protocol. I believe that in practice operators want to go on using the management protocols that they already have deployed. If, for example, I have deployed routers that I manage using SNMP, I will not want to deploy a new routing protocol on those routers if that protocol is strongly recommended to be managed using TL1. Since data modeling is usually tied closely to the protocol used for management, it follows from this that developing specific data formats (SNMP MIB modules, XML schema, etc.) might also not be so very practical. (Arguably we have found this out with MIB modules over the last 10 years, but still churn them out.) What *would* be beneficial, however, is an abstract data model for management of the protocol. There are many ways of representing the data (XML, BNF, ASN.1, graphical representation, etc.) and the Ops Area could usefully pick one and standardise it. From there we would have a solid data set that all implementations could make available and which separate documents could easily map to suitable formats for use by specific management protocols. Smart implementers would be able to support multiple management protocols with ease. You do come to this to some extent in section 4.1, and the text there seems to be at odds with what you have said in the Introduction. === Section 1 Can you expand "WG" on first usage? === Section 1 We want to avoid seeming to impose a solution by putting in place a strict terminology - for example implying that a formal data model, or even using a management protocol is mandatory. You want to avoid seeming to impose it? So, you want to impose it, but you don't want anyone to notice? === Section 1 Making a Management Considerations section a mandatory publication requirement for IETF documents is the responsibility of the IESG, or specific area directors, or working groups, and this document avoids recommending any mandatory publication requirements. I think you may need to go a step further to get this through the IESG. It would not be funny to see this paragraph as written, but to get a DISCUSS on an I-D from an Ops AD because the I-D did not contain a Management Considerations section. === Introduction We provide some objective criteria to promote interoperability There seems to be only one author. Are you royalty? Perhaps... "This document provides..." === Section 1 final line s/??/?"/ === 2.1. IETF Management Framework For years the IETF has stressed the use of the IETF Standard Management Framework and MIB modules [RFC2578] for managing new protocols. The IETF designed these to permit multiple protocols to utilize the MIB data [RFC1052], but it became a common s/became/is/ === 3.1. Operations Model o what are the typical user interfaces - Command line (CLI) or graphical user interface (GUI)? I am not sure that this last item is particularly relevant for a large number of the protocols designed in the IETF. We might say that the question is valid for a protocol such as FTP, but is it relevant for OSPF? Yes, there is a configuration interface to a device that runs OSPF, but it is surely nothing to do with the protocol design how that interface works. Indeed, you might reduce the question to: are the configuration interfaces local or remote? But I think you will find that the answer to the question is "both" as in the subsequent paragraph. === 3.1. Operations Model Auto-configuration and default parameters might be possible for some new protocols. I would make a much bigger noise about default parameters. There is a key question about how the protocol can operate "out of the box". If implementers are free to select their own defaults, the protocol needs to operate well with any choice of values. If there are sensible defaults, these need to be stated. Indeed, section 3.2 seems to say this. Perhaps a forward reference? === 3.1. Operations Model There may be a need to support a human interface, e.g., for troubleshooting, and a programmatic interface, e.g., for automated monitoring and root cause analysis. It might be important that the internal method routines used by the application programming interfaces and the human interfaces should be the same to ensure that data exchanged between these two interfaces is always consistent. Mixing methods leads to inconsistency, so identifying consistent methods of retrieving information is relevant. This is really sailing too close to the implementation. People must be free to construct sub-standard and unmarketable implementations. The IETF is not responsible for making all implementations successful. The job is to make it possible for all implementations to be successful given core competences in the developers. I think the furthest a protocol spec RFC could go would be to say what information must be available to an operator at a human interface for troubleshooting === 3.2. Installation and Initial Setup In view of the reasons you give why defaults might become out- dated, you might point out that sometimes it is not advisable to have defaults. In these cases explicit configuration is required. === 3.2. Installation and Initial Setup Is the text at the top of page 8 supposed to be a bullet list? === 3.4. Requirements on Other Protocols and Functional Components These considerations should generally remain illustrative to avoid creating restrictions or dependencies, or potentially impacting the behavior of existing protocols, or restricting the extensibility of other protocols, or assuming other protocols will not be extended in certain ways. Well, this is quite interesting. Suppose you decide to utilise a particular feature of a transport protocol. You are creating a hard requirement that that feature is implemented in all implementations of the set {your new protocol, the transport protocol}. But more importantly, perhaps, you are requiring that new versions of the transport protocol do not deprecate the feature you require. In short, I don't think you should be too nervous about creating restrictions or dependencies. If they exist, they must be stated. === 3.2. Installation and Initial Setup For example, the design of Resource ReSerVation Protocol (RSVP) I think this example is not well expressed. The problem in RSVP was that the IP packet was addressed to the ultimate RSVP-capable destination, but the RSVP-capable routers along the path needed to intercept and process the Path message. This they could only do by "deep packet inspection" or by the router alert option. I wonder whether this example adds significantly to the I-D. === 4. Management Considerations NETCONF addresses this in a generic manner by Add citation. === 4. Management Considerations However, debugging on-the-wire interactions is a protocol issue: it is enormously helpful if a protocol has hooks to make debugging of network interactions easy, and/or is designed in such a way that debugging protocol behaviors is easy. Hand-waving this away is not something that operators like ... I think you are including this by hand-waving! What do you mean by "hooks"? Surely any protocol can be debugged simply by sniffing it. If you have specific hooks in mind you must set them out and not leave the reader guessing. But if you force the implementation I shall be peeved! You might, for example, say that there should be alerts issued when messages are received, or when there are state transitions in the protocol state machine, but you must recall that: - the messages can be seen by sniffing - the state machine is not part of the protocol specification. This latter point is key. The state machine explains how the protocol works in order that an implementer can decide how to react to a received event, but it does not require that the machine is implemented. === 4.1. Interoperability Interoperability needs to be considered on the syntactic level and the semantic level. While it can be irritating and time-consuming, application designers including operators who write their own scripts can make their processing conditional to accommodate differences s/differences/syntactic differences/ ? Then, whether the counter is gathered via SNMP or a CLI command or a SYSLOG message, the counter will have similar meaning. "similar"? I think that might not be good enough. Don't you need "the same"? o [RFC3805] - Printer MIB v2 (contains both an IM and a DM Missing ")" === 4.2. Management Information I would find it really helpful if you were able to recommend a language in which to write the information model. Ideally, all IETF IMs would be in the same language. It is important to be able to separately fetch configuration data, operational state data, and statistics from devices, and to be able to compare current state to initial state, and to compare data between devices. You seem to have drifted into DMs here. You cannot fetch data from an IM. It simply explains what data elements exist. In fact, an IM states all of the data that exists and so there is no confusion. Confusion can only arise as the DM is constructed and multiple IM data elements are conflated into single DM objects. === 4.3. Fault Management The protocol designer should document the basic faults and health indicators that need to be instrumented for the new protocol, and the alarms and events that must be propagated to management applications or exposed through a data model. Isn't "propagated to management applications" a subset of "exposed through a data model"? The protocol designer should consider how faults information will be s/faults/fault/ Should the event reporting provide gyaranteed accurate delivery of s/gyaranteed/guaranteed/ === 4.3.3. Fault Isolation It might be useful to isolate faults, such as a system that emits malformed messages necessary to coordinate connections properly. Spanning tree comes to mind. This might be able to be done by configuring next-hop devices to drop the faulty messages to prevent them from entering the rest of the network. This is not what *I* mean by fault isolation! Fault isolation is about working out where in the network the fault is. For example, if end-to-end data delivery is failing (reported by a notification), fault isolation will find the failed link or node in the end-to-end path. You seem to be describing the process of quarantining faulty devices. This may also be valuable. "Spanning tree comes to mind" is a rather strange sentence without much context. === 4.4. Configuration Management A protocol desoigners should document what the basic configuration s/desoigners/designers/ "Requirements for Configuration Management of IP-based Networks" [RFC3139] discusses requirements for configuration management. More precisely, "Requirements for Configuration Management of IP-based Networks" [RFC3139] discusses requirements for configuration management of IP-based networks. Which makes me wonder about the purpose of the sentence :-) This document includes... This document or that document? A number of efforts have existed in the IETF to develop policy-based management. "Terminology for Policy-Based Management" [RFC3198] was written to standardize the terminology across these efforts. Some of the efforts resulted in proposals that are NOT RECOMMENDED, so a protocol designer should check the current recommendation status before depending on a specific protocol suggestion. You have used RFC2119 language, but in section 1.1 you said This document deliberately does not use the (capitalized) keywords described in RFC 2119 [RFC2119]. Furthermore, it is not clear to me whether this I-D is doing the NOT RECOMMENDing or whether some other RFC has done it. If it is this I-D, you will need to give reasons. If is some other RFC, you will need to give references. It is highly desirable that text processing tools such as diff, and version management tools such as RCS or CVS or SVN, can be used to process configurations. This approach simplifies comparing the current operational state to the initial configuration. It is commonplace to compare configuration changes to e.g., last day, last week, last month, etc. -- having configuration in a text, and human- understandable format is very valuable for various reasons such as change control (or verification), configuration consistency checks, etc. Yes, but what has this to do with the protocol design? It might be related to device implementation. Or it might be relevant to EMS/NMS implementation. As you note in the subsequent paragraph, this may be impossible even in some text-based DMs. It would certainly be impossible in an SNMP MIB module. To simplify such configuration comparisons, devices should not arbitrarily reorder data such as access control lists. If a protocol designer defines mechanisms for configuration, it would be desirable to standardize the order of elements for consistency of configuration and of reporting across vendors, and across releases from vendors. This example seems a bit specific. And in any case, it is perfectly possible to sort a list before comparing. There are two parts to this: 1. An NMS system could optimize ACLs for performance reasons 2. Unless the device/NMS systems has correct rules/a lot of experience, reordering ACLs can lead to a huge security issue. Maybe what you are saying is: Implementations should not arbitrarily modify configuration data. In some cases (such as Access Control Lists) the order of data items is significant and comprises part of the configured data. Network wide configurations are ideally stored in central master databases This looks like an unsubstantiated assertion. You might get away with "Many operators prefer that..." It is important to distinguish between the distribution of configurations and the activation of a certain configuration. Devices should be able to hold multiple configurations. This is really an implementation issue and nothing to do with the protocol under design. Consensus of the 2002 IAB Workshop was that textual configuration files should be able to contain international characters. Do you have a citation? These timers may need default values suggested in the protocol specification and do not need to be otherwise configurable. I had formed the opinion that timers must be given default values in IETF protocol specifications, but I can't lay my hands on a reference. === 4.5. Accounting Management A protocol designer should consider whether it would be appropriate to collect usage information related to this protocol, and if so, what usage information would be appropriate to collect? s/collect?/collect./ "Introduction to Accounting Management" [RFC2975] discusses a number of factors relevant to monitoring usage of protocols for purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document also discusses how Remote Authentication Dial In User This or that? Service (RADIUS) [RFC2865], Terminal Access Controller Access Control System (TACACS) [RFC1492], SNMP, IPFIX, and Packet Sampling (PSAMP) Protocol [I-D.ietf-psamp-protocol] protocols can be used for these purposes. Surely RFC 2975 does not mention PSAMP? Which makes me wonder what you are trying to achieve with a list of example protocols. Are they intended as recommendations (in which case say so and why), or as a non-exclusive list (in which case a "such as" would be useful). At the moment it reads like these are your favorites and you would be upset if someone used a different protocol! === 4.6. Performance Management There are several parts to performance management to be considered: protocol monitoring, services monitoring, and device monitoring (the impact of the new protocol/service activation on the device). s/services/service/ Consider scalability, such as whether performance will be affected by the number of protocol connections. Maybe say "protocol entities" rather than connections? This section seems to flit between the performance of the protocol under design and the network running the protocol under design, and the performance of the management of the protocol. Each is important, but it may be constructive to split them out into separate sections. The latter will also include a consideration of how the act of monitoring impacts on network performance. The Benchmarking Methodology WG (bmwg) has defined recommendations Later you have BMWG. === 4.7. Security Management It must be possible to do consistency checks of access control lists across devices. Protocol designers should consider information models to promote comparisons across devices and across vendors to permit checking the consistency of security configurations. I think this "must" is massively excessive! I would expect each router to have a different access list in the control plane (a list of its neighbors). Such a mechanism would actually open up a security vulnerability that has to be protected. Perhaps you are talking about management plane access lists. This takes us into the area of securing management activity - see my comments on Section 7. RADIUS and DIAMETER can provide authentication and authorization. A protocol designer should consider which attributes would be appropriate for their protocol. This paragraph is apropos of what? What are you trying to tell me? Should I run my management using Radius? Should I try to build Diameter into my new protocol? Different protocols use different assumptions about message security s/protocols/management protocols/ and data access controls. A protocol designer that recommends using different protocols should consider how security will be applied in a s/protocols/management protocols/ Although you talk about (presumably management) access lists, I think I would have expected a discussion of authority levels and policy with regard to management tasks. === 7. Security Considerations This document is informational and provides guidelines for considering manageability and operations. It introduces no new security concerns. I think that, although you introduce no new security concerns directly, you have some things to talk about. Firstly, the provision of a management portal to a network device provides a doorway through which an attack on the device may be launched. Since you are recommending that the protocol under development be manageable through the management protocol, you are requiring that the protocol be vulnerable to a new source of attacks. Therefore, you must talk about securing the protocol against these attacks. This might be as simple as saying that only management protocols with adequate (for some definition of adequate) security apparatus be used. I think it is also of note that a standard description of the manageable knobs and whistles on a protocol makes it easier for an attacker to understand what they may try to control and how to tweak it. On the other hand, it would be well worth pointing out that a well-designed protocol is usually more stable and secure. And that a protocol that can be managed and inspected offers the operator a better chance of spotting and quarantining any attacks. Conversely making a protocol inspectable, is a risk if the wrong person inspects it! If security events cause logs and or notifications/alerts, can a concerted attack be mounted by causing an excess of these events? In other words, to the security management mechanisms constitute the security vulnerability? Lastly, the management of security aspects is important, and you can just reference back to section 4.7. === 9. Informative References I (of course) would favor an informational reference to draft-ietf-pce- manageability-requirements-06.txt === [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. I think this has been obsoleted. === Appendix A. Operations and Management Review Checklist Maybe a forward reference to this appendix from sections 1 and 5? === A.3. Documentation Does the proposed protocol have a significant operational impact on the Internet. If it does, and the document under review targets standards track, is their enough proof of implementation and/or operational experience to grant Proposed Standard status? Whoah! You are going to use this I-D to try to block standards track I-Ds from becoming RFCs? You are going to get into such a fight!!! IMHO this sentence is a complete show-stopper in your I-D. (Oh, and s/their/there/) === Appendix B. Change Log Suggest you flag this for removal upon publication as an RFC. === > Sent: Sunday, January 25, 2009 6:40 PM > To: opsawg@ietf.org > Subject: [OPSAWG] (final) WGLC on > draft-ietf-opsawg-operations-and-management > > This is a (hopefully final) WGLC for > draft-ietf-opsawg-operations-and-management > there was not enough respose to the last one back in October > please let the list know what you think of the draft From ietfdbh@comcast.net Wed Feb 4 13:16:08 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 7CC9528C12A for ; Wed, 4 Feb 2009 13:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 30uwNJ1rXOBl for ; Wed, 4 Feb 2009 13:16:06 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id BC7953A6974 for ; Wed, 4 Feb 2009 13:16:05 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA07.westchester.pa.mail.comcast.net with comcast id BptV1b00F0xGWP857xFmcz; Wed, 04 Feb 2009 21:15:46 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id BxFk1b01D0UQ6dC3YxFlJ3; Wed, 04 Feb 2009 21:15:46 +0000 From: "David Harrington" To: "'Adrian Farrel'" , References: <5C8D68E9DDC2439B82F3CC0591A54F05@your029b8cecfe> Date: Wed, 4 Feb 2009 16:15:43 -0500 Message-ID: <057101c9870d$be4cd240$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5C8D68E9DDC2439B82F3CC0591A54F05@your029b8cecfe> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmHAwhCHKmVtP94QQigwXoGZssxzQACqAIw Cc: 'David B Harrington' , tseely5@gmail.com Subject: Re: [OPSAWG] (final) WGLC ondraft-ietf-opsawg-operations-and-management 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, 04 Feb 2009 21:16:08 -0000 Wow! Adrian wants me to do some work! Thanks for the thorough review. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, February 04, 2009 2:55 PM > To: opsawg@ietf.org > Cc: David B Harrington; tseely5@gmail.com > Subject: Re: [OPSAWG] (final) WGLC > ondraft-ietf-opsawg-operations-and-management > > Hi, > > Dan asked me to have a look at this which I do primarily with > a routing area > view on the world. > > I'm sorry that I haven't been following this I-D very closely > and apologise > if you have already discussed and reached conclusion on some > of the points I > make. > > I am largely supportive of this work (see > draft-ietf-pce-manageability-requirements-06.txt), but I do have some > issues. I would be comforted to know that the I-D had had > extensive review > from within the Ops Area without relying just on my comments! > > I would also like to understand how the recommendations parts > of the draft > will be interpreted by the Ops ADs as they perform IESG > review of I-Ds from > other areas. Depending on the answer (which I would like to > see encapsulated > in the document!) I might have other harsher comments about > the content. > > More details below. > > Cheers, > Adrian > > === > Title is... > Guidelines for Considering Operations and Management of New Protocols > ...but the Abstract immediately includes... > New protocols or protocol extensions > === > Obviously needs the new IPR boilerplate. > === > Abstract line 3 > s/protocol/protocols/ > === > I am somewhat worried by "recommend appropriate standard management > protocols ... to address the relevant operations and management > needs." > > I understand the theory behind this guidance in terms of making > equipment that will interwork with management systems, but I > question its practicality given the vast array of management > protocols available. And actually, I am not sure that this has a > direct impact on the success of or development of a protocol. > > The introduction says that this "is similar to a WG considering > which security threats are relevant to their protocol, and then > recommending appropriate standard security protocols to mitigate > the relevant threats." I dispute this. The security considerations > normally make modifications to the protocol under development to > make it secure, or mandate security features in other protocols > that the protocol under development uses. But where there is a > need for an external protocol, this is not usually mandated. For > example, where key exchange is needed the text will usually say > something like "may use some form of secure key exchange protocol > (such as the Internet Key Exchange protocol v2 (IKE) [RFC4306]." > This is far looser than a recommendation of a specific protocol. > > I believe that in practice operators want to go on using the > management protocols that they already have deployed. If, for > example, I have deployed routers that I manage using SNMP, I will > not want to deploy a new routing protocol on those routers if that > protocol is strongly recommended to be managed using TL1. > > Since data modeling is usually tied closely to the protocol used > for management, it follows from this that developing specific > data formats (SNMP MIB modules, XML schema, etc.) might also not > be so very practical. (Arguably we have found this out with MIB > modules over the last 10 years, but still churn them out.) > > What *would* be beneficial, however, is an abstract data model > for management of the protocol. There are many ways of > representing the data (XML, BNF, ASN.1, graphical representation, > etc.) and the Ops Area could usefully pick one and standardise > it. From there we would have a solid data set that all > implementations could make available and which separate documents > could easily map to suitable formats for use by specific > management protocols. Smart implementers would be able to support > multiple management protocols with ease. > > You do come to this to some extent in section 4.1, and the text > there seems to be at odds with what you have said in the > Introduction. > > === > Section 1 > > Can you expand "WG" on first usage? > > === > Section 1 > > We want to avoid seeming to impose a solution by putting in place a > strict terminology - for example implying that a formal data model, > or even using a management protocol is mandatory. > > > > You want to avoid seeming to impose it? > So, you want to impose it, but you don't want anyone to notice? > > > > === > Section 1 > > Making a Management Considerations section a mandatory publication > requirement for IETF documents is the responsibility of > the IESG, or > specific area directors, or working groups, and this > document avoids > recommending any mandatory publication requirements. > > I think you may need to go a step further to get this through the > IESG. It would not be funny to see this paragraph as written, but > to get a DISCUSS on an I-D from an Ops AD because the I-D did not > contain a Management Considerations section. > > === > Introduction > > We provide some objective criteria to promote interoperability > > > > There seems to be only one author. Are you royalty? > Perhaps... "This document provides..." > > > > === > Section 1 final line > > s/??/?"/ > > === > > 2.1. IETF Management Framework > > For years the IETF has stressed the use of the IETF Standard > Management Framework and MIB modules [RFC2578] for managing new > protocols. The IETF designed these to permit multiple protocols to > utilize the MIB data [RFC1052], but it became a common > > s/became/is/ > > === > > 3.1. Operations Model > > o what are the typical user interfaces - Command line (CLI) or > graphical user interface (GUI)? > > I am not sure that this last item is particularly relevant for a > large number of the protocols designed in the IETF. We might say > that the question is valid for a protocol such as FTP, but is it > relevant for OSPF? Yes, there is a configuration interface to a > device that runs OSPF, but it is surely nothing to do with the > protocol design how that interface works. Indeed, you might > reduce the question to: are the configuration interfaces local or > remote? But I think you will find that the answer to the question > is "both" as in the subsequent paragraph. > > === > > 3.1. Operations Model > > Auto-configuration and default parameters might be > possible for some new protocols. > > I would make a much bigger noise about default parameters. There is > a key question about how the protocol can operate "out of the box". > If implementers are free to select their own defaults, the protocol > needs to operate well with any choice of values. If there are > sensible defaults, these need to be stated. > > Indeed, section 3.2 seems to say this. Perhaps a forward reference? > > === > > 3.1. Operations Model > > There may be a need to support a human interface, e.g., for > troubleshooting, and a programmatic interface, e.g., for automated > monitoring and root cause analysis. It might be important that the > internal method routines used by the application programming > interfaces and the human interfaces should be the same to > ensure that > data exchanged between these two interfaces is always consistent. > Mixing methods leads to inconsistency, so identifying consistent > methods of retrieving information is relevant. > > This is really sailing too close to the implementation. People > must be free to construct sub-standard and unmarketable > implementations. The IETF is not responsible for making all > implementations successful. The job is to make it possible for > all implementations to be successful given core competences in the > developers. > > I think the furthest a protocol spec RFC could go would be to say > what information must be available to an operator at a human > interface for troubleshooting > > === > > 3.2. Installation and Initial Setup > > In view of the reasons you give why defaults might become out- > dated, you might point out that sometimes it is not advisable to > have defaults. In these cases explicit configuration is required. > > === > > 3.2. Installation and Initial Setup > > Is the text at the top of page 8 supposed to be a bullet list? > > === > > 3.4. Requirements on Other Protocols and Functional Components > > These considerations should generally remain illustrative to avoid > creating restrictions or dependencies, or potentially impacting the > behavior of existing protocols, or restricting the extensibility of > other protocols, or assuming other protocols will not be > extended in > certain ways. > > Well, this is quite interesting. > > Suppose you decide to utilise a particular feature of a transport > protocol. You are creating a hard requirement that that feature is > implemented in all implementations of the set {your new protocol, > the transport protocol}. But more importantly, perhaps, you are > requiring that new versions of the transport protocol do not > deprecate the feature you require. > > In short, I don't think you should be too nervous about creating > restrictions or dependencies. If they exist, they must be stated. > > === > > 3.2. Installation and Initial Setup > > For example, the design of Resource ReSerVation Protocol (RSVP) > > I think this example is not well expressed. > > The problem in RSVP was that the IP packet was addressed to the > ultimate RSVP-capable destination, but the RSVP-capable routers > along the path needed to intercept and process the Path message. > This they could only do by "deep packet inspection" or by the > router alert option. > > I wonder whether this example adds significantly to the I-D. > > === > > 4. Management Considerations > > NETCONF addresses this in a generic manner by > > Add citation. > > === > > 4. Management Considerations > > However, debugging on-the-wire interactions is a protocol > issue: it is enormously helpful if a protocol has hooks to make > debugging of network interactions easy, and/or is designed > in such a > way that debugging protocol behaviors is easy. > Hand-waving this away > is not something that operators like ... > > I think you are including this by hand-waving! > What do you mean by "hooks"? > Surely any protocol can be debugged simply by sniffing it. > If you have specific hooks in mind you must set them out and not > leave the reader guessing. > But if you force the implementation I shall be peeved! > You might, for example, say that there should be alerts issued when > messages are received, or when there are state transitions in the > protocol state machine, but you must recall that: > - the messages can be seen by sniffing > - the state machine is not part of the protocol specification. > This latter point is key. The state machine explains how the > protocol works in order that an implementer can decide how to > react to a received event, but it does not require that the > machine is implemented. > > === > > 4.1. Interoperability > > Interoperability needs to be considered on the syntactic level and > the semantic level. While it can be irritating and time-consuming, > application designers including operators who write their > own scripts > can make their processing conditional to accommodate differences > > s/differences/syntactic differences/ ? > > Then, whether the counter is gathered via SNMP or a CLI > command or a SYSLOG message, the counter will have similar meaning. > > "similar"? I think that might not be good enough. Don't you need > "the same"? > > o [RFC3805] - Printer MIB v2 (contains both an IM and a DM > > Missing ")" > > === > > 4.2. Management Information > > I would find it really helpful if you were able to recommend a > language in which to write the information model. Ideally, all > IETF IMs would be in the same language. > > It is important to be able to separately fetch configuration data, > operational state data, and statistics from devices, and to be able > to compare current state to initial state, and to compare data > between devices. > > You seem to have drifted into DMs here. You cannot fetch data from > an IM. It simply explains what data elements exist. In fact, an IM > states all of the data that exists and so there is no confusion. > Confusion can only arise as the DM is constructed and multiple IM > data elements are conflated into single DM objects. > > === > > 4.3. Fault Management > > The protocol designer should document the basic faults and health > indicators that need to be instrumented for the new > protocol, and the > alarms and events that must be propagated to management > applications > or exposed through a data model. > > Isn't "propagated to management applications" a subset of "exposed > through a data model"? > > The protocol designer should consider how faults > information will be > > s/faults/fault/ > > Should the event reporting provide gyaranteed accurate delivery of > s/gyaranteed/guaranteed/ > > === > > 4.3.3. Fault Isolation > > It might be useful to isolate faults, such as a system that emits > malformed messages necessary to coordinate connections properly. > Spanning tree comes to mind. This might be able to be done by > configuring next-hop devices to drop the faulty messages to prevent > them from entering the rest of the network. > > This is not what *I* mean by fault isolation! > Fault isolation is about working out where in the network the fault > is. For example, if end-to-end data delivery is failing (reported by > a notification), fault isolation will find the failed link or node > in the end-to-end path. > > You seem to be describing the process of quarantining faulty > devices. This may also be valuable. > > "Spanning tree comes to mind" is a rather strange sentence without > much context. > > === > > 4.4. Configuration Management > > A protocol desoigners should document what the basic configuration > > s/desoigners/designers/ > > "Requirements for Configuration Management of IP-based Networks" > [RFC3139] discusses requirements for configuration management. > More precisely, > "Requirements for Configuration Management of IP-based Networks" > [RFC3139] discusses requirements for configuration management of > IP-based networks. > Which makes me wonder about the purpose of the sentence :-) > > This document includes... > This document or that document? > > A number of efforts have existed in the IETF to develop > policy-based > management. "Terminology for Policy-Based Management" > [RFC3198] was > written to standardize the terminology across these > efforts. Some of > the efforts resulted in proposals that are NOT RECOMMENDED, so a > protocol designer should check the current recommendation status > before depending on a specific protocol suggestion. > > You have used RFC2119 language, but in section 1.1 you said > This document deliberately does not use the (capitalized) keywords > described in RFC 2119 [RFC2119]. > Furthermore, it is not clear to me whether this I-D is doing the > NOT RECOMMENDing or whether some other RFC has done it. If it is > this I-D, you will need to give reasons. If is some other RFC, you > will need to give references. > > It is highly desirable that text processing tools such as diff, and > version management tools such as RCS or CVS or SVN, can be used to > process configurations. This approach simplifies comparing the > current operational state to the initial configuration. It is > commonplace to compare configuration changes to e.g., last > day, last > week, last month, etc. -- having configuration in a text, > and human- > understandable format is very valuable for various reasons such as > change control (or verification), configuration consistency checks, > etc. > > Yes, but what has this to do with the protocol design? It might be > related to device implementation. Or it might be relevant to > EMS/NMS implementation. > > As you note in the subsequent paragraph, this may be impossible > even in some text-based DMs. It would certainly be impossible in > an SNMP MIB module. > > To simplify such configuration comparisons, devices should not > arbitrarily reorder data such as access control lists. If > a protocol > designer defines mechanisms for configuration, it would be > desirable > to standardize the order of elements for consistency of > configuration > and of reporting across vendors, and across releases from vendors. > > This example seems a bit specific. And in any case, it is perfectly > possible to sort a list before comparing. > > There are two parts to this: 1. An NMS system could optimize ACLs > for performance reasons 2. Unless the device/NMS systems > has correct > rules/a lot of experience, reordering ACLs can lead to a huge > security issue. > > Maybe what you are saying is: > Implementations should not arbitrarily modify configuration data. > In some cases (such as Access Control Lists) the order of data > items is significant and comprises part of the configured data. > > Network wide configurations are ideally stored in central master > databases > > This looks like an unsubstantiated assertion. You might get away > with "Many operators prefer that..." > > It is important to distinguish between the distribution of > configurations and the activation of a certain configuration. > Devices should be able to hold multiple configurations. > > This is really an implementation issue and nothing to do with the > protocol under design. > > Consensus of the 2002 IAB Workshop was that textual configuration > files should be able to contain international characters. > > Do you have a citation? > > These timers may need default values > suggested in the protocol specification and do not need to be > otherwise configurable. > > I had formed the opinion that timers must be given default values > in IETF protocol specifications, but I can't lay my hands on a > reference. > > === > > 4.5. Accounting Management > > A protocol designer should consider whether it would be appropriate > to collect usage information related to this protocol, and if so, > what usage information would be appropriate to collect? > > s/collect?/collect./ > > "Introduction to Accounting Management" [RFC2975] > discusses a number > of factors relevant to monitoring usage of protocols for > purposes of > capacity and trend analysis, cost allocation, auditing, > and billing. > This document also discusses how Remote Authentication Dial In User > This or that? > > Service (RADIUS) [RFC2865], Terminal Access Controller > Access Control > System (TACACS) [RFC1492], SNMP, IPFIX, and Packet Sampling (PSAMP) > Protocol [I-D.ietf-psamp-protocol] protocols can be used for these > purposes. > > Surely RFC 2975 does not mention PSAMP? Which makes me wonder what > you are trying to achieve with a list of example protocols. Are > they intended as recommendations (in which case say so and why), > or as a non-exclusive list (in which case a "such as" would be > useful). At the moment it reads like these are your favorites and > you would be upset if someone used a different protocol! > > === > > 4.6. Performance Management > > There are several parts to performance management to be considered: > protocol monitoring, services monitoring, and device > monitoring (the > impact of the new protocol/service activation on the device). > > s/services/service/ > > Consider scalability, such as whether performance will be > affected by > the number of protocol connections. > > Maybe say "protocol entities" rather than connections? > > > This section seems to flit between the performance of the protocol > under design and the network running the protocol under design, and > the performance of the management of the protocol. Each is > important, but it may be constructive to split them out into > separate sections. The latter will also include a consideration of > how the act of monitoring impacts on network performance. > > > The Benchmarking Methodology WG (bmwg) has defined recommendations > Later you have BMWG. > > === > > 4.7. Security Management > > It must be possible to do consistency checks of access > control lists > across devices. Protocol designers should consider information > models to promote comparisons across devices and across vendors to > permit checking the consistency of security configurations. > > I think this "must" is massively excessive! > I would expect each router to have a different access list in the > control plane (a list of its neighbors). Such a mechanism would > actually open up a security vulnerability that has to be protected. > Perhaps you are talking about management plane access lists. This > takes us into the area of securing management activity - see my > comments on Section 7. > > RADIUS and DIAMETER can provide authentication and > authorization. A > protocol designer should consider which attributes would be > appropriate for their protocol. > > This paragraph is apropos of what? What are you trying to tell me? > Should I run my management using Radius? Should I try to build > Diameter into my new protocol? > > Different protocols use different assumptions about > message security > s/protocols/management protocols/ > > and data access controls. A protocol designer that > recommends using > different protocols should consider how security will be > applied in a > s/protocols/management protocols/ > > > Although you talk about (presumably management) access lists, I think > I would have expected a discussion of authority levels and policy > with regard to management tasks. > > === > > 7. Security Considerations > > This document is informational and provides guidelines for > considering manageability and operations. It introduces no new > security concerns. > > I think that, although you introduce no new security concerns > directly, you have some things to talk about. > > Firstly, the provision of a management portal to a network device > provides a doorway through which an attack on the device may be > launched. Since you are recommending that the protocol under > development be manageable through the management protocol, you are > requiring that the protocol be vulnerable to a new source of > attacks. Therefore, you must talk about securing the protocol > against these attacks. This might be as simple as saying that only > management protocols with adequate (for some definition of > adequate) security apparatus be used. > > I think it is also of note that a standard description of the > manageable knobs and whistles on a protocol makes it easier for an > attacker to understand what they may try to control and how to > tweak it. > > On the other hand, it would be well worth pointing out that a > well-designed protocol is usually more stable and secure. And that > a protocol that can be managed and inspected offers the operator > a better chance of spotting and quarantining any attacks. > Conversely making a protocol inspectable, is a risk if the wrong > person inspects it! > > If security events cause logs and or notifications/alerts, can > a concerted attack be mounted by causing an excess of these > events? In other words, to the security management mechanisms > constitute the security vulnerability? > > Lastly, the management of security aspects is important, and you > can just reference back to section 4.7. > > === > > 9. Informative References > > I (of course) would favor an informational reference to > draft-ietf-pce- > manageability-requirements-06.txt > > === > > [RFC2821] Klensin, J., "Simple Mail Transfer > Protocol", RFC 2821, April 2001. > > I think this has been obsoleted. > > === > > Appendix A. Operations and Management Review Checklist > > Maybe a forward reference to this appendix from sections 1 and 5? > > === > > A.3. Documentation > > Does the proposed protocol have a significant operational impact on > the Internet. If it does, and the document under review targets > standards track, is their enough proof of implementation and/or > operational experience to grant Proposed Standard status? > > Whoah! > > You are going to use this I-D to try to block standards track I-Ds > from becoming RFCs? You are going to get into such a fight!!! > > IMHO this sentence is a complete show-stopper in your I-D. > > (Oh, and s/their/there/) > > === > > Appendix B. Change Log > > Suggest you flag this for removal upon publication as an RFC. > > === > > > Sent: Sunday, January 25, 2009 6:40 PM > > To: opsawg@ietf.org > > Subject: [OPSAWG] (final) WGLC on > > draft-ietf-opsawg-operations-and-management > > > > This is a (hopefully final) WGLC for > > draft-ietf-opsawg-operations-and-management > > there was not enough respose to the last one back in October > > please let the list know what you think of the draft > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From dbharrington@comcast.net Wed Feb 4 14:16:58 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 616623A6934 for ; Wed, 4 Feb 2009 14:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 SC3ZckZ8VlWp for ; Wed, 4 Feb 2009 14:16:57 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 66D693A6921 for ; Wed, 4 Feb 2009 14:16:57 -0800 (PST) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA01.westchester.pa.mail.comcast.net with comcast id BnQD1b0031HzFnQ51yG4mx; Wed, 04 Feb 2009 22:16:04 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id ByGe1b00K0UQ6dC3ayGecE; Wed, 04 Feb 2009 22:16:38 +0000 From: "David B Harrington" To: , "'Natale, Bob'" References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> <17969D855F28964C88D177D45B6CDF11F2296C7C@IMCMBX2.MITRE.ORG> <17969D855F28964C88D177D45B6CDF11F2296C82@IMCMBX2.MITRE.ORG> <17969D855F28964C88D177D45B6CDF11F2296C8E@IMCMBX2.MITRE.ORG> <035601c98566$2e94ec80$0600a8c0@china.huawei.com> Date: Wed, 4 Feb 2009 17:16:36 -0500 Message-ID: <058001c98716$3f329680$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <035601c98566$2e94ec80$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmCf+6Dw0EjDHCoReukukGWp0iR7ACspMxgAArzYzAAAGcj0AAAFHfAAAFle2AAal8+YA== Subject: [OPSAWG] WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.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: Wed, 04 Feb 2009 22:16:58 -0000 Hi, I have reviewed the -04- revision and believe it is in good shape, with the following recommended changes. I think it should be published as a standards track RFC. Recommended changes: 1) Abstract s/(when approved as a standards-track RFC)// 2) Introduction I recommend dropping the part about three documents unless you actually publish initial versions of the other documents. I do recommend against creating a tarball of the three documents, which would hold up all three until all are complete. So dropping the text makes the most sense to me. On the other hand, this document alone is insufficient. Users of this document may also need the other two documents, depending on their purpose. You could say that the other two documents may be needed for complete reuse of existing MIB modules in an XML environment, but those documents have not been written at the time of this writing. 3) section 4 The paragraph about "BITS" needs to be modified: s/will be defined/????/ 4) IANA Considerations The document registers namespaces and schemas for three documents. This should be changed to only register one set. 5) Acknowledgements check the spelling of Alfred HInes. you or the RFC editor should remove the note to notify the editor. 6) References I think RFC3584 might be Normative, and 2579 Informational. 7) Open Issues remove this section 8) Change Log you or the RFC editor should remove the change log 9) copyrights need to be 2009, and must meet the new IPR rules. 10) Since this schema might be used separately from the enclosing document, should it contain information, similar to the description in a MIB module, such as organization, contact person, address, phone, email, last updated, the RFC in which it was published, etc.? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From RNATALE@mitre.org Wed Feb 4 14:26:12 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 A248D3A6AC2 for ; Wed, 4 Feb 2009 14:26:12 -0800 (PST) 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=[AWL=0.000, 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 8Dv-uvDQkdOv for ; Wed, 4 Feb 2009 14:26:11 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id B502F3A685A for ; Wed, 4 Feb 2009 14:26:11 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n14MPpku021575 for ; Wed, 4 Feb 2009 17:25:51 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n14MPpoR021567; Wed, 4 Feb 2009 17:25:51 -0500 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 4 Feb 2009 17:25:51 -0500 From: "Natale, Bob" To: David B Harrington Date: Wed, 4 Feb 2009 17:25:49 -0500 Thread-Topic: WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt Thread-Index: AcmCf+6Dw0EjDHCoReukukGWp0iR7ACspMxgAArzYzAAAGcj0AAAFHfAAAFle2AAal8+YAAB7D4A Message-ID: <17969D855F28964C88D177D45B6CDF11F22978B2@IMCMBX2.MITRE.ORG> References: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> <17969D855F28964C88D177D45B6CDF11F2296C7C@IMCMBX2.MITRE.ORG> <17969D855F28964C88D177D45B6CDF11F2296C82@IMCMBX2.MITRE.ORG> <17969D855F28964C88D177D45B6CDF11F2296C8E@IMCMBX2.MITRE.ORG> <035601c98566$2e94ec80$0600a8c0@china.huawei.com> <058001c98716$3f329680$0600a8c0@china.huawei.com> In-Reply-To: <058001c98716$3f329680$0600a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.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: Wed, 04 Feb 2009 22:26:12 -0000 Hi David, Thanks...will implement your recommended changes 1-9 per your guidance (and= earlier feedback from others). I don't really know the answer to 10...will watch for additional comments f= rom this group and will research what has been done for some other XSDs in = IETF RFCs...and adopt what results from that or leave it as is if nothing e= merges clearly. Cheers, BobN -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Wednesday, February 04, 2009 5:17 PM To: opsawg@ietf.org; Natale, Bob Subject: WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt Hi, I have reviewed the -04- revision and believe it is in good shape, with the following recommended changes. I think it should be published as a standards track RFC. Recommended changes: 1) Abstract s/(when approved as a standards-track RFC)// 2) Introduction =20 I recommend dropping the part about three documents unless you actually publish initial versions of the other documents. I do recommend against creating a tarball of the three documents, which would hold up all three until all are complete. So dropping the text makes the most sense to me. On the other hand, this document alone is insufficient. Users of this document may also need the other two documents, depending on their purpose. You could say that the other two documents may be needed for complete reuse of existing MIB modules in an XML environment, but those documents have not been written at the time of this writing. 3) section 4 The paragraph about "BITS" needs to be modified: s/will be defined/????/ 4) IANA Considerations The document registers namespaces and schemas for three documents. This should be changed to only register one set. 5) Acknowledgements check the spelling of Alfred HInes. you or the RFC editor should remove the note to notify the editor. 6) References I think RFC3584 might be Normative, and 2579 Informational. 7) Open Issues remove this section 8) Change Log you or the RFC editor should remove the change log 9) copyrights need to be 2009, and must meet the new IPR rules. 10) Since this schema might be used separately from the enclosing document, should it contain information, similar to the description in a MIB module, such as organization, contact person, address, phone, email, last updated, the RFC in which it was published, etc.? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From bertietf@bwijnen.net Wed Feb 4 14:45:04 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 03A1A3A6A20 for ; Wed, 4 Feb 2009 14:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.059 X-Spam-Level: X-Spam-Status: No, score=-0.059 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 LmuOqQqEmtck for ; Wed, 4 Feb 2009 14:45:02 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 369D03A68F7 for ; Wed, 4 Feb 2009 14:45:00 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LUqU3-0002zQ-TP for opsawg@ietf.org; Wed, 04 Feb 2009 23:44:40 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: Date: Wed, 4 Feb 2009 23:41:27 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B1B_01C98722.19240A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [OPSAWG] Fw: start WGLC ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.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: Wed, 04 Feb 2009 22:45:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0B1B_01C98722.19240A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Using my ietf user account, so the mailing list accepts my posting. I believe Bob has already answered. Bert Bert ----- Original Message -----=20 From: Bert Wijnen=20 To: Natale, Bob=20 Cc: opsawg@ietf.org=20 Sent: Wednesday, February 04, 2009 5:39 PM Subject: Re: [OPSAWG] start WGLC on = draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt W.r.t. my second point, section 4 states: This document concerns only the SMI base datatypes -- i.e., the eleven "ObjectSyntax" datatypes defined in RFC2578. These = datatypes -- via tag values defined in the SMI to identify them in varbinds = -- constrain values carried "on-the-wire" in SNMP PDUs between SNMP management applications and SNMP agents: And then after that colon, it lists the names of the dtaatypes as you = define them in sect 4, namely the names used in teh XSD. If they refer to SMI datatype, then I would have expected OBJECT = IDENTIFIER instead of ObjectIdentifier and OCTET STRING instead of OctetString. Not a big deal, but it had me put on the wrong leg at first. By the way, in teh IANA considerations there is also text and URIs = w.r.t. "other 2 documents" in the "set of documents". Bert ----- Original Message -----=20 From: Natale, Bob=20 To: Bert Wijnen (IETF)=20 Cc: opsawg@ietf.org=20 Sent: Wednesday, February 04, 2009 2:17 PM Subject: RE: [OPSAWG] start WGLC on = draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt Hi Bert, =20 Thanks for your comments and assessment. =20 - The misspellings of "opaque" (with a "g") have been corrected. =20 - The use of "datatypes" in the file name and title was, in fact, = intended to refer to "SMI datatypes" as implied by the general usage in = RFC 2578, Sec. 7.1, "Mapping of the Syntax Clause", to wit: =20 "The SYNTAX clause, which must be present, defines the abstract data = structure corresponding to that object. The data structure must be one = of the following: a base type, the BITS construct, or a textual = convention. (SEQUENCE OF and SEQUENCE are also possible for conceptual = tables, see section 7.1.12). The base types are those defined in the = ObjectSyntax CHOICE. A textual convention is a newly-defined type = defined as a sub-type of a base type [3]." =20 So, "datatypes" is used a bit loosely for "base types".would you = prefer that the latter term be used? (The document text currently makes = it clear that it deals only with expressing the base types of RFC 2578 = in XSD.) =20 - Yes, the text that Juergen questioned is being removed (also had = helpful guidance from David Harrington on this point), so that this = "base types" document stands alone. =20 Please confirm or clarify the second point.I will have the -05 = version, reflecting final mods based on this last call round, ready = immediately after expiration of the last call period (12-Feb-09). =20 Cheers, BobN =20 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf Of Bert Wijnen (IETF) Sent: Wednesday, February 04, 2009 4:57 AM To: opsawg@ietf.org Subject: Re: [OPSAWG] start WGLC = ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt =20 My comments: =20 - page 7, section 4 - speaks about opague. I think you mean opaque (with a Q) =20 You may also want to make an explicit statement that those are the = datatype names as ytou specify them in XSD. I first though they were the = datatypes as specified in SMIv2. =20 =20 - Opague (with a G) is again used in the 1st para of sect 5.3 and=20 in the first bullet on page 12 and also 3rd bullet. =20 I share/support Juergen Shoenwaelder's comment w.r.t. the discussion = about 3 documents in a document set. Where, how is that otehr work scheduled/planned? =20 Other than that, this document seems fine. =20 Bert ----- Original Message -----=20 From: Scott O. Bradner=20 To: opsawg@ietf.org=20 Sent: Friday, January 30, 2009 3:10 AM Subject: Re: [OPSAWG] start WGLC = ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt =20 back on Nov 6th we sent out a WGLC on=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt there was no response to that last call that I can=20 find in the mail list archive (or in my memory) we gotta see a bit more interest than that to proceed with this document. =20 So, I'll try again=20 this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt please comment (one way or the other) by Feb 12 tnx Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_0B1B_01C98722.19240A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Using my ietf user account, so the mailing list = accepts my=20 posting.
 
I believe Bob has already answered.
 
Bert
 
Bert
----- Original Message -----=20
From: Bert = Wijnen=20
Sent: Wednesday, February 04, 2009 5:39 PM
Subject: Re: [OPSAWG] start WGLC on=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

W.r.t. my second point, section 4 = states:
 
   This document concerns only the SMI = base=20 datatypes -- i.e., the
   eleven "ObjectSyntax" datatypes = defined=20 in RFC2578.  These datatypes
   -- via tag values = defined in=20 the SMI to identify them in varbinds --
   constrain = values=20 carried "on-the-wire" in SNMP PDUs between SNMP
   = management=20 applications and SNMP agents:
 
And then after that colon, it lists the names of = the=20 dtaatypes as you define them in sect 4, namely
the names used in teh XSD.
 
If they refer to SMI datatype, then I would have = expected=20 OBJECT IDENTIFIER instead of
ObjectIdentifier and OCTET STRING instead of=20 OctetString.
 
Not a big deal, but it had me put on the wrong leg = at=20 first.
 
By the way, in teh IANA considerations there is = also text=20 and URIs w.r.t.
"other 2 documents" in the "set of = documents".
 
Bert
----- Original Message -----
From:=20 Natale, Bob=20
Sent: Wednesday, February 04, = 2009 2:17=20 PM
Subject: RE: [OPSAWG] start = WGLC on=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

Hi=20 Bert,

 

Thanks=20 for your comments and assessment.

 

-=20 The misspellings of =93opaque=94 (with a =93g=94) have been=20 corrected.

 

-=20 The use of =93datatypes=94 in the file name and title was, in fact, = intended to=20 refer to =93SMI datatypes=94 as implied by the general usage in RFC = 2578, Sec.=20 7.1, =93Mapping of the Syntax Clause=94, to = wit:

 

=93The=20 SYNTAX clause, which must be present, defines the abstract data = structure=20 corresponding to that object.  The data structure must be one = of the=20 following: a base type, the BITS construct, or a textual = convention. =20 (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, = see=20 section 7.1.12).  The base types are those defined in the = ObjectSyntax=20 CHOICE.  A textual convention is a newly-defined type defined = as a=20 sub-type of a base type [3].=94

 

So,=20 =93datatypes=94 is used a bit loosely for =93base types=94=85would = you prefer that the=20 latter term be used?  (The document text currently makes it = clear that=20 it deals only with expressing the base types of RFC 2578 in=20 XSD.)

 

-=20 Yes, the text that Juergen questioned is being removed (also had = helpful=20 guidance from David Harrington on this point), so that this =93base = types=94=20 document stands alone.

 

Please=20 confirm or clarify the second point=85I will have the -05 version, = reflecting=20 final mods based on this last call round, ready immediately after = expiration=20 of the last call period (12-Feb-09).

 

Cheers,

BobN

 

From:=20 opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf Of=20 Bert Wijnen (IETF)
Sent: Wednesday, February 04, 2009 = 4:57=20 AM
To: opsawg@ietf.org
Subject: Re: [OPSAWG] = start WGLC=20 = ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

 

My comments:

 

- page 7, section = 4

  - speaks about opague. I think you = mean=20 opaque (with a Q)

 

  You may also want to make an = explicit=20 statement that those are the datatype

  names as ytou specify them in XSD. = I first=20 though they were the datatypes

  as specified in=20 SMIv2.

 

 

- Opague (with a G) is again used in the = 1st para of=20 sect 5.3 and 

   in the first bullet on page = 12 and also=20 3rd bullet.

 

I share/support Juergen Shoenwaelder's = comment=20 w.r.t. the discussion about 3 documents

in a document set. Where, how is that = otehr work=20 scheduled/planned?

 

Other than that, this document seems=20 fine.

 

Bert

----- = Original=20 Message -----

From: Scott O. = Bradner=20

To: opsawg@ietf.org=20

Sent: = Friday,=20 January 30, 2009 3:10 AM

Subject: Re: = [OPSAWG]=20 start WGLC=20 = ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

 


back on Nov = 6th we sent=20 out a WGLC on=20
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

there was = no=20 response to that last call that I can
find in the mail list = archive=20 (or in my memory)

we gotta see a bit more interest than = that to=20 proceed
with this document. 

So, I'll try again=20

this is a WGLC for=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt
please comment = (one way=20 or the other) by Feb=20 = 12

tnx

Scott
___________________________________________= ____
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

------=_NextPart_000_0B1B_01C98722.19240A80-- From heard@pobox.com Wed Feb 4 20:10:13 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 99B0A3A69B6 for ; Wed, 4 Feb 2009 20:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 pgTiG-1k1soH for ; Wed, 4 Feb 2009 20:10:08 -0800 (PST) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by core3.amsl.com (Postfix) with ESMTP id 337ED3A67BD for ; Wed, 4 Feb 2009 20:10:05 -0800 (PST) Received: (qmail 21704 invoked from network); 4 Feb 2009 20:09:45 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Feb 2009 20:09:45 -0800 Date: Wed, 4 Feb 2009 20:09:45 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPSAWG In-Reply-To: <20090127083743.GB12355@elstar.local> Message-ID: References: <20090125164013.802B5129CDC6@newdev.eecs.harvard.edu> <20090127083743.GB12355@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 04 Feb 2009 23:38:13 -0800 Subject: Re: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management 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, 05 Feb 2009 04:10:13 -0000 Dan R. asked me to provide comments. I am not able to do a detailed review of the document, but based on a quick reading I have to say that I am in general agreement with Juergen Schoenwaelder's high-level comments. On Tue, 27 Jan 2009, Juergen Schoenwaelder wrote: > My review of draft-ietf-opsawg-operations-and-management-05.txt: > > I find this a difficult document to review and I like to state clearly > upfront that I very much appreciate the efforts spend on putting this > document together. The reason for starting with this diclaimer is that > I find it difficult to provide constructive comments in the form of > concrete suggestions for changes. While reading, I observed the > following: > > - The document makes a distinction between "Operational > Considerations" (section 3) and "Management Considerations" (section > 4) and I am not sure where the difference really is. I appears that > section 4 is much more management technology oriented and organized > following the FCAPS model but in general, I do not really see why > some issues are operational considerations and others management > considerations. Perhaps the document can be streamlined by merging > these two sections together. (For example, 3.6 and 4.3.1 do in my > view pretty much belong together.) +1 > - I am not sure the discussion what the "IETF Management Framework" > means (historically and today) is that useful for designers of new > protocols and it might raise controversial discussions. +1 One specific example of "might raised controversial discussions":: For years the IETF has stressed the use of the IETF Standard Management Framework and MIB modules [RFC2578] for managing new protocols. The IETF designed these to permit multiple protocols to utilize the MIB data [RFC1052], but it became a common misunderstanding that a MIB module could only be used with the SNMP protocol (described in [RFC3410] and associated documents). With what other protocols have MIB modules ever been used??? > Why not replace this material with a section that provide a > high-level summary of the management technologies that can be > considered by protocol designers? In terms of structure, this > could mean that the document should have this structure (in > terms of top-level sections): > > 1. Introduction > 2. Available Management Technologies > (briefly mention SNMP, SYSLOG, RADIUS/DIAMETER, NETCONF, IPFIX, > CLIs, GUIs, ... and outline where they are particularly strong > and where not; this should be short and not a long elaboration) > 3. Operational and Management Considerations > 4. Documentation Guidelines > .. ... > > This would lift some of the text currently in section 4 into section > 2. I also killed the current section 2 since the core of this is > already discussed in the introduction. As an alterntative, one could > keep a section "Design for Operations and Management" but then some > of the discussion currently in the introduction should be moved. +1 > - The "Terminology" section explains why RFC 2119 language is not used > and then defines the terms "new protocol" and "protocol designers". > The document later has quite some text related to terminology (e.g. > the discussion of information model vs. data model). One option to > consider is to move all text discussing or clarifying terminology > into this "Terminology" section (including the text fragments > pointing to RFC 3198 and RFC 3444). +1 //cmh From j.schoenwaelder@jacobs-university.de Mon Feb 9 23:30: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 D52283A6C54 for ; Mon, 9 Feb 2009 23:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, UNPARSEABLE_RELAY=0.001] 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 JaFRL8v8pF5R for ; Mon, 9 Feb 2009 23:30:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 005343A6C21 for ; Mon, 9 Feb 2009 23:30:32 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 106C6C003B for ; Tue, 10 Feb 2009 08:30:34 +0100 (CET) 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 OdNG-VyTrhVp for ; Tue, 10 Feb 2009 08:30:27 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92541C0024 for ; Tue, 10 Feb 2009 08:30:27 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 62F4D98FEF5; Tue, 10 Feb 2009 08:30:26 +0100 (CET) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 10 Feb 2009 08:30:26 +0100 Resent-Message-ID: <20090210073026.GA3509@elstar.iuhb02.iu-bremen.de> Resent-To: opsawg@ietf.org Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.3.11) with LMTPA; Tue, 10 Feb 2009 01:01:24 +0100 X-Sieve: CMU Sieve 2.3 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by merkur.jacobs-university.de (Postfix) with ESMTP id 522195CD43 for ; Tue, 10 Feb 2009 01:01:24 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by atlas1.jacobs-university.de (Postfix) with ESMTP id 4B56652E for ; Tue, 10 Feb 2009 01:01:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas1b.jacobs-university.de ([212.201.44.13]) by localhost (demetrius2.jacobs-university.de [212.201.44.47]) (amavisd-new, port 10030) with ESMTP id hXdKEgN1EVsR for ; Tue, 10 Feb 2009 01:01:17 +0100 (CET) X-JacobsISPWhiteListed: med ietf.org DNSWLId 1703 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by atlas1b.jacobs-university.de (Postfix) with ESMTP for ; Tue, 10 Feb 2009 01:01:17 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B0628C186; Mon, 9 Feb 2009 16:00:03 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1F95D28C18D; Mon, 9 Feb 2009 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090210000002.1F95D28C18D@core3.amsl.com> Date: Mon, 9 Feb 2009 16:00:02 -0800 (PST) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org Subject: [OPSAWG] I-D ACTION:draft-schoenw-syslog-msg-mib-02.txt X-BeenThere: opsawg@ietf.org Reply-To: internet-drafts@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 07:30:53 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Author(s) : J. Schoenwaelder, A. Clemm, A. Karmakar Filename : draft-schoenw-syslog-msg-mib-02.txt Pages : 21 Date : 2009-2-9 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-syslog-msg-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-schoenw-syslog-msg-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-2-9154553.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From j.schoenwaelder@jacobs-university.de Mon Feb 9 23:33:45 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 545AF3A6C4D for ; Mon, 9 Feb 2009 23:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 QzUnZe4rvv5f for ; Mon, 9 Feb 2009 23:33:44 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 31FE43A6C49 for ; Mon, 9 Feb 2009 23:33:44 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C46FCC002A; Tue, 10 Feb 2009 08:33:46 +0100 (CET) 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 eU66+jFOPF-k; Tue, 10 Feb 2009 08:33:40 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D849C0024; Tue, 10 Feb 2009 08:33:40 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 8591998FF6F; Tue, 10 Feb 2009 08:33:39 +0100 (CET) Date: Tue, 10 Feb 2009 08:33:39 +0100 From: Juergen Schoenwaelder To: Juergen Quittek , Dan Romascanu , "Scott O. Bradner" , opsawg@ietf.org Message-ID: <20090210073339.GB3509@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Juergen Quittek , Dan Romascanu , "Scott O. Bradner" , opsawg@ietf.org References: <20090129230053.GA14953@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090129230053.GA14953@elstar.local> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 07:33:45 -0000 On Fri, Jan 30, 2009 at 12:00:53AM +0100, Juergen Schoenwaelder wrote: > On Sun, Jan 25, 2009 at 02:17:40AM +0100, Juergen Quittek wrote: > > > Below please find a review of draft-schoenw-syslog-msg-mib-01. > > Thanks for your detailed and helpful review. I have posted which I think addresses all issues raised and all open issues marked in the previous edition of this document. In other words, I believe this document is complete. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Tue Feb 10 06:00:02 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0954628C178; Tue, 10 Feb 2009 06:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090210140002.0954628C178@core3.amsl.com> Date: Tue, 10 Feb 2009 06:00:02 -0800 (PST) Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.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: Tue, 10 Feb 2009 14:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Author(s) : J. Schoenwaelder, et al. Filename : draft-ietf-opsawg-syslog-msg-mib-00.txt Pages : 21 Date : 2009-02-10 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsawg-syslog-msg-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-10055531.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Feb 10 06:00:02 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0CCEA28C1C0; Tue, 10 Feb 2009 06:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090210140002.0CCEA28C1C0@core3.amsl.com> Date: Tue, 10 Feb 2009 06:00:02 -0800 (PST) Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-snmp-00.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: Tue, 10 Feb 2009 14:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages Author(s) : V. Marinov, J. Schoenwaelder Filename : draft-ietf-opsawg-syslog-snmp-00.txt Pages : 14 Date : 2009-02-10 This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-snmp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsawg-syslog-snmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-10055623.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Tue Feb 10 06:51:12 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 4E3303A6A55 for ; Tue, 10 Feb 2009 06:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 GoYoPHchh7A9 for ; Tue, 10 Feb 2009 06:51:11 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id E33E43A6BEE for ; Tue, 10 Feb 2009 06:51:10 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LWtxA-0001Gq-KY for opsawg@ietf.org; Tue, 10 Feb 2009 15:51:12 +0100 Message-ID: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <20090210140002.0954628C178@core3.amsl.com> In-Reply-To: <20090210140002.0954628C178@core3.amsl.com> Date: Tue, 10 Feb 2009 15:50:54 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F4_01C98B97.5B5B6A50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.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: Tue, 10 Feb 2009 14:51:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02F4_01C98B97.5B5B6A50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess that the reason for using so many DisplayStrings is the fact = that the unerlying syslog messages are ASCII (probably even just the subset allowed in = DisplayString) based ?? One could still represent them in UTF-8 based objects... and be prepared = for future international language support? In any event, if you want to stick to DsiplayString, it would probably = be good to explain why this is justified, given the fact that we DISCOURAGE use of = DisplayString these days, Bert ----- Original Message -----=20 From: Internet-Drafts@ietf.org=20 To: i-d-announce@ietf.org=20 Cc: opsawg@ietf.org=20 Sent: Tuesday, February 10, 2009 3:00 PM Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Operations and Management Area = Working Group Working Group of the IETF. Title : Definitions of Managed Objects for Mapping SYSLOG = Messages to Simple Network Management Protocol (SNMP) Notifications Author(s) : J. Schoenwaelder, et al. Filename : draft-ietf-opsawg-syslog-msg-mib-00.txt Pages : 21 Date : 2009-02-10 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-00.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------------= ----- _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_02F4_01C98B97.5B5B6A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I guess that the reason for using so many = DisplayStrings is=20 the fact that the unerlying syslog
messages are ASCII (probably even just the = subset allowed=20 in DisplayString) based ??
 
One could still represent them in UTF-8 based = objects... and=20 be prepared for future
international language support?
 
In any event, if you want to stick to DsiplayString, = it would=20 probably be good to explain
why this is justified, given the fact that we = DISCOURAGE use=20 of DisplayString these days,
 
Bert
----- Original Message -----
From:=20 Internet-Drafts@ietf.org =
Sent: Tuesday, February 10, = 2009 3:00=20 PM
Subject: [OPSAWG] I-D=20 Action:draft-ietf-opsawg-syslog-msg-mib-00.txt

A New Internet-Draft is available from the on-line=20 Internet-Drafts directories.
This draft is a work item of the = Operations=20 and Management Area Working Group Working Group of the=20 = IETF.


Title        &nb= sp; =20 : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple = Network=20 Management Protocol (SNMP)=20 Notifications
Author(s)       : J.=20 Schoenwaelder, et = al.
Filename        :=20 = draft-ietf-opsawg-syslog-msg-mib-00.txt
Pages    &= nbsp;     =20 : = 21
Date          &nb= sp;=20 : 2009-02-10

This memo defines a portion of the Management = Information=20 Base (MIB)
for use with network management protocols in the = Internet=20 community.
In particular, it defines a mapping of SYSLOG messages = to=20 Simple
Network Management Protocol (SNMP) notifications.

A = URL for=20 this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-= msg-mib-00.txt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-= drafts/

Below=20 is the data which will enable a MIME compliant mail = reader
implementation=20 to automatically retrieve the ASCII version of = the
Internet-Draft.

_______________________________________________
OPSAWG = mailing=20 list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg
------=_NextPart_000_02F4_01C98B97.5B5B6A50-- From j.schoenwaelder@jacobs-university.de Tue Feb 10 07:49: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 127F13A6B96 for ; Tue, 10 Feb 2009 07:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 vb-6xUdiZHyw for ; Tue, 10 Feb 2009 07:49:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8E7F63A69C3 for ; Tue, 10 Feb 2009 07:49:01 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3CE60C004E; Tue, 10 Feb 2009 16:49:04 +0100 (CET) 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 fObXOst6ARsM; Tue, 10 Feb 2009 16:48:57 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9D47C004A; Tue, 10 Feb 2009 16:48:57 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id DFAEB991989; Tue, 10 Feb 2009 16:48:56 +0100 (CET) Date: Tue, 10 Feb 2009 16:48:56 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20090210154856.GD5949@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Bert Wijnen (IETF)" , opsawg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 15:49:03 -0000 On Tue, Feb 10, 2009 at 03:50:54PM +0100, Bert Wijnen (IETF) wrote: > I guess that the reason for using so many DisplayStrings is the fact > that the unerlying syslog messages are ASCII (probably even just the > subset allowed in DisplayString) based ?? Yes. > One could still represent them in UTF-8 based objects... and be > prepared for future international language support? The IETF version of SYSLOG is relatively new; since it passed IESG review relatively recently, should I really bother that fields might not be internationalization ready? > In any event, if you want to stick to DsiplayString, it would > probably be good to explain why this is justified, given the fact > that we DISCOURAGE use of DisplayString these days, Where is this policy stated? I tried to match the protocol - do I have to state explicitely somewhere (for each object?) that the definitions tries to match the protocol? At the end, I do not care since these are not writable objects. But if we make them UTF8, we should probably add an explanation that they won't really carry non ASCII characters with today's version of SYSLOG and that the UTF8 type is only there to future proof the definitions in case there could ever be UTF8 encoded characters. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Feb 10 07:56:02 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 CCEFF3A6B9A for ; Tue, 10 Feb 2009 07:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 lJpr78LCj8oM for ; Tue, 10 Feb 2009 07:56:02 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id DD4523A69C3 for ; Tue, 10 Feb 2009 07:56:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,187,1233550800"; d="scan'208";a="151756685" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 10 Feb 2009 10:56:03 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 10 Feb 2009 10:56:02 -0500 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: Tue, 10 Feb 2009 16:55:58 +0100 Message-ID: In-Reply-To: <20090210154856.GD5949@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString Thread-Index: AcmLlx5MPKXRZxyhRhWqHB3ca7hAhQAALzbA References: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210154856.GD5949@elstar.iuhb02.iu-bremen.de> From: "Romascanu, Dan (Dan)" To: , "Bert Wijnen (IETF)" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString 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, 10 Feb 2009 15:56:02 -0000 =20 > -----Original Message----- > From: opsawg-bounces@ietf.org=20 > [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder .... >=20 > > In any event, if you want to stick to DsiplayString, it=20 > would probably=20 > > be good to explain why this is justified, given the fact that we=20 > > DISCOURAGE use of DisplayString these days, >=20 > Where is this policy stated? I tried to match the protocol -=20 > do I have to state explicitely somewhere (for each object?)=20 > that the definitions tries to match the protocol? Appendix B, Note 2 in RFC4181 says: DisplayString does not support internationalized text. It MUST NOT be used for objects that are required to hold internationalized text (which is always the case if the object is intended for use by humans [RFC2277]). Designers SHOULD consider using SnmpAdminString, Utf8String, or LongUtf8String for such objects. >=20 > At the end, I do not care since these are not writable=20 > objects. But if we make them UTF8, we should probably add an=20 > explanation that they won't really carry non ASCII characters=20 > with today's version of SYSLOG and that the UTF8 type is only=20 > there to future proof the definitions in case there could=20 > ever be UTF8 encoded characters. ;-) >=20 > /js >=20 > Dan From j.schoenwaelder@jacobs-university.de Tue Feb 10 08:15:18 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 CA6BF3A6C8E for ; Tue, 10 Feb 2009 08:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 cAQBY8mmlgqv for ; Tue, 10 Feb 2009 08:15:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 81BD13A6BAE for ; Tue, 10 Feb 2009 08:15:17 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86E5CC0010; Tue, 10 Feb 2009 17:15:20 +0100 (CET) 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 yluaqVxpw-Dj; Tue, 10 Feb 2009 17:15:11 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 007C2C004A; Tue, 10 Feb 2009 17:15:10 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 09303991AD8; Tue, 10 Feb 2009 17:15:09 +0100 (CET) Date: Tue, 10 Feb 2009 17:15:09 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090210161509.GB6082@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Bert Wijnen (IETF)" , opsawg@ietf.org References: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210154856.GD5949@elstar.iuhb02.iu-bremen.de> 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] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 16:15:18 -0000 On Tue, Feb 10, 2009 at 04:55:58PM +0100, Romascanu, Dan (Dan) wrote: > > > > > In any event, if you want to stick to DsiplayString, it > > would probably > > > be good to explain why this is justified, given the fact that we > > > DISCOURAGE use of DisplayString these days, > > > > Where is this policy stated? I tried to match the protocol - > > do I have to state explicitely somewhere (for each object?) > > that the definitions tries to match the protocol? > > Appendix B, Note 2 in RFC4181 says: > > DisplayString does not support internationalized text. It > MUST NOT be used for objects that are required to hold > internationalized text (which is always the case if the > object is intended for use by humans [RFC2277]). Designers > SHOULD consider using SnmpAdminString, Utf8String, or > LongUtf8String for such objects. > > > > At the end, I do not care since these are not writable > > objects. But if we make them UTF8, we should probably add an > > explanation that they won't really carry non ASCII characters > > with today's version of SYSLOG and that the UTF8 type is only > > there to future proof the definitions in case there could > > ever be UTF8 encoded characters. ;-) All fine, but in this case, the protocol elements modeled do not support non ASCII characters and so is there a policy that even in cases where the protocol is ASCII, DisplayString is DISCOURAGED in favour of some other string format? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Feb 10 08:20:45 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 A31733A680F for ; Tue, 10 Feb 2009 08:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 K2mOdGfo4BF1 for ; Tue, 10 Feb 2009 08:20:44 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5C10D3A6805 for ; Tue, 10 Feb 2009 08:20:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,187,1233550800"; d="scan'208";a="136989753" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Feb 2009 11:20:45 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Feb 2009 11:20:44 -0500 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: Tue, 10 Feb 2009 17:20:35 +0100 Message-ID: In-Reply-To: <20090210161509.GB6082@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString Thread-Index: AcmLmsdqBRVecHEJRD61AUaKdwMS3AAAC9hg References: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210154856.GD5949@elstar.iuhb02.iu-bremen.de> <20090210161509.GB6082@elstar.iuhb02.iu-bremen.de> From: "Romascanu, Dan (Dan)" To: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString 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, 10 Feb 2009 16:20:45 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Tuesday, February 10, 2009 6:15 PM > To: Romascanu, Dan (Dan) > Cc: Bert Wijnen (IETF); opsawg@ietf.org > Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString >=20 > On Tue, Feb 10, 2009 at 04:55:58PM +0100, Romascanu, Dan (Dan) wrote: > > >=20 > > > > In any event, if you want to stick to DsiplayString, it > > > would probably > > > > be good to explain why this is justified, given the=20 > fact that we=20 > > > > DISCOURAGE use of DisplayString these days, > > >=20 > > > Where is this policy stated? I tried to match the protocol - do I=20 > > > have to state explicitely somewhere (for each object?) that the=20 > > > definitions tries to match the protocol? > >=20 > > Appendix B, Note 2 in RFC4181 says: > >=20 > > DisplayString does not support=20 > internationalized text. It > > MUST NOT be used for objects that are required to hold > > internationalized text (which is always the case if the > > object is intended for use by humans=20 > [RFC2277]). Designers > > SHOULD consider using SnmpAdminString, Utf8String, or > > LongUtf8String for such objects. > > >=20 > > > At the end, I do not care since these are not writable=20 > objects. But=20 > > > if we make them UTF8, we should probably add an explanation that=20 > > > they won't really carry non ASCII characters with today's=20 > version of=20 > > > SYSLOG and that the UTF8 type is only there to future proof the=20 > > > definitions in case there could ever be UTF8 encoded=20 > characters. ;-) >=20 > All fine, but in this case, the protocol elements modeled do=20 > not support non ASCII characters and so is there a policy=20 > that even in cases where the protocol is ASCII, DisplayString=20 > is DISCOURAGED in favour of some other string format? >=20 Not that I am aware, and I am ready to stand corrected if I miss something. Using DisplayString in this case seems OK to me, however, a sentence to explain this in the DESCRIPTION cause cannot harm, for folks who may come across the issue later.=20 Dan From cfinss@dial.pipex.com Tue Feb 10 10:18: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 B485E3A69DF for ; Tue, 10 Feb 2009 10:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_05=-1.11, 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 5u5X1NiIFi8F for ; Tue, 10 Feb 2009 10:18:48 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 4A3DD3A6A99 for ; Tue, 10 Feb 2009 10:18:48 -0800 (PST) X-Trace: 185131691/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.69/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.69 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: AlUFACBUkUk+vGRF/2dsb2JhbABFgwAtFooTtwUJjx0BBoJcgTcG X-IronPort-AV: E=Sophos;i="4.38,187,1233532800"; d="scan'208";a="185131691" X-IP-Direction: IN Received: from 1cust69.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.69]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Feb 2009 18:18:49 +0000 Message-ID: <000701c98ba3$7ebe4a60$0601a8c0@allison> From: "tom.petch" To: , References: <20081120200500.GA2973@elstar.local> Date: Tue, 10 Feb 2009 12:31:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents 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: Tue, 10 Feb 2009 18:18:49 -0000 In syslog-msg-mib, is the value of an SD-PARAM stored with or without the escaping? syslog needs the escapes because of the syntax of the syslog message, BER.1 does not so they could be removed. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Thursday, November 20, 2008 9:05 PM Subject: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents > Hi, > > the chairs of this WG need to decide whether there is support for > adopting (a) a document defining a new SD-ID to represent SNMP > notifications in SYSLOG [1] and (b) a document defining a MIB module > representing SYSLOG messages [2]. For an overview, see the > presentation slides form the Dublin meeting [3]. > > I believe that the documents are already pretty mature and can likely > go through the WG relatively quickly. There has been quite some > support for this work in Dublin and Rainer Gerhards expressed his > support on the list. I am aware that some people did contact the > chairs directly expressing their support but it might make things > easier to move this forward if people can actually express their > support here. > > Thanks, > > /js > > [1] http://tools.ietf.org/html/draft-marinov-syslog-snmp-02 > (15 pages) > [2] http://tools.ietf.org/html/draft-schoenw-syslog-msg-mib-01 > (18 pages) > [3] http://www.ietf.org/proceedings/08jul/slides/opsawg-1.pdf > > -- > 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 cfinss@dial.pipex.com Tue Feb 10 10:19: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 EF3753A6CA1 for ; Tue, 10 Feb 2009 10:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 vFU8gUQuwvSc for ; Tue, 10 Feb 2009 10:18:58 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 353D13A6CA6 for ; Tue, 10 Feb 2009 10:18:56 -0800 (PST) X-Trace: 185131696/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.69/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.69 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: AjkFACBUkUk+vGRF/2dsb2JhbACDRS0WihPGKweCUAGBQgY X-IronPort-AV: E=Sophos;i="4.38,187,1233532800"; d="scan'208";a="185131696" X-IP-Direction: IN Received: from 1cust69.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.69]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Feb 2009 18:18:50 +0000 Message-ID: <000801c98ba3$80df0780$0601a8c0@allison> From: "tom.petch" To: "Adrian Farrel" , References: <5C8D68E9DDC2439B82F3CC0591A54F05@your029b8cecfe> Date: Tue, 10 Feb 2009 18:04:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: David B Harrington , tseely5@gmail.com Subject: Re: [OPSAWG] (final) WGLC ondraft-ietf-opsawg-operations-and-management 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: Tue, 10 Feb 2009 18:19:01 -0000 I was going to say +1 to Juergen's comments and then I was going to say +1 to Mike's comments and then I was going to say +1 to Adrian's comments and while I was pondering, ... I left it too late:-( But I do echo much of what has been said. I cannot see that this I-D lives up to its billing. It is a good idea, and it is good stuff (give or take some infelicities of wording, most of which have been pointed out already) but I do not see it as good stuff for a working group coming up with a new protocol, say an MPLS-TP or sieve or sidr. And that is what I think is needed. If something is not designed to be managed ab initio, then it may be costly, impossible even, to manage it in the wild. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: Cc: "David B Harrington" ; Sent: Wednesday, February 04, 2009 8:54 PM Subject: Re: [OPSAWG] (final) WGLC ondraft-ietf-opsawg-operations-and-management > Hi, > > Dan asked me to have a look at this which I do primarily with a routing area > view on the world. > > I'm sorry that I haven't been following this I-D very closely and apologise > if you have already discussed and reached conclusion on some of the points I > make. > > I am largely supportive of this work (see > draft-ietf-pce-manageability-requirements-06.txt), but I do have some > issues. I would be comforted to know that the I-D had had extensive review > from within the Ops Area without relying just on my comments! > > I would also like to understand how the recommendations parts of the draft > will be interpreted by the Ops ADs as they perform IESG review of I-Ds from > other areas. Depending on the answer (which I would like to see encapsulated > in the document!) I might have other harsher comments about the content. > > More details below. > > Cheers, > Adrian > > === > Title is... > Guidelines for Considering Operations and Management of New Protocols > ...but the Abstract immediately includes... > New protocols or protocol extensions > === > Obviously needs the new IPR boilerplate. > === > Abstract line 3 > s/protocol/protocols/ > === > I am somewhat worried by "recommend appropriate standard management > protocols ... to address the relevant operations and management > needs." > > I understand the theory behind this guidance in terms of making > equipment that will interwork with management systems, but I > question its practicality given the vast array of management > protocols available. And actually, I am not sure that this has a > direct impact on the success of or development of a protocol. > > The introduction says that this "is similar to a WG considering > which security threats are relevant to their protocol, and then > recommending appropriate standard security protocols to mitigate > the relevant threats." I dispute this. The security considerations > normally make modifications to the protocol under development to > make it secure, or mandate security features in other protocols > that the protocol under development uses. But where there is a > need for an external protocol, this is not usually mandated. For > example, where key exchange is needed the text will usually say > something like "may use some form of secure key exchange protocol > (such as the Internet Key Exchange protocol v2 (IKE) [RFC4306]." > This is far looser than a recommendation of a specific protocol. > > I believe that in practice operators want to go on using the > management protocols that they already have deployed. If, for > example, I have deployed routers that I manage using SNMP, I will > not want to deploy a new routing protocol on those routers if that > protocol is strongly recommended to be managed using TL1. > > Since data modeling is usually tied closely to the protocol used > for management, it follows from this that developing specific > data formats (SNMP MIB modules, XML schema, etc.) might also not > be so very practical. (Arguably we have found this out with MIB > modules over the last 10 years, but still churn them out.) > > What *would* be beneficial, however, is an abstract data model > for management of the protocol. There are many ways of > representing the data (XML, BNF, ASN.1, graphical representation, > etc.) and the Ops Area could usefully pick one and standardise > it. From there we would have a solid data set that all > implementations could make available and which separate documents > could easily map to suitable formats for use by specific > management protocols. Smart implementers would be able to support > multiple management protocols with ease. > > You do come to this to some extent in section 4.1, and the text > there seems to be at odds with what you have said in the > Introduction. > > === > Section 1 > > Can you expand "WG" on first usage? > > === > Section 1 > > We want to avoid seeming to impose a solution by putting in place a > strict terminology - for example implying that a formal data model, > or even using a management protocol is mandatory. > > > > You want to avoid seeming to impose it? > So, you want to impose it, but you don't want anyone to notice? > > > > === > Section 1 > > Making a Management Considerations section a mandatory publication > requirement for IETF documents is the responsibility of the IESG, or > specific area directors, or working groups, and this document avoids > recommending any mandatory publication requirements. > > I think you may need to go a step further to get this through the > IESG. It would not be funny to see this paragraph as written, but > to get a DISCUSS on an I-D from an Ops AD because the I-D did not > contain a Management Considerations section. > > === > Introduction > > We provide some objective criteria to promote interoperability > > > > There seems to be only one author. Are you royalty? > Perhaps... "This document provides..." > > > > === > Section 1 final line > > s/??/?"/ > > === > > 2.1. IETF Management Framework > > For years the IETF has stressed the use of the IETF Standard > Management Framework and MIB modules [RFC2578] for managing new > protocols. The IETF designed these to permit multiple protocols to > utilize the MIB data [RFC1052], but it became a common > > s/became/is/ > > === > > 3.1. Operations Model > > o what are the typical user interfaces - Command line (CLI) or > graphical user interface (GUI)? > > I am not sure that this last item is particularly relevant for a > large number of the protocols designed in the IETF. We might say > that the question is valid for a protocol such as FTP, but is it > relevant for OSPF? Yes, there is a configuration interface to a > device that runs OSPF, but it is surely nothing to do with the > protocol design how that interface works. Indeed, you might > reduce the question to: are the configuration interfaces local or > remote? But I think you will find that the answer to the question > is "both" as in the subsequent paragraph. > > === > > 3.1. Operations Model > > Auto-configuration and default parameters might be > possible for some new protocols. > > I would make a much bigger noise about default parameters. There is > a key question about how the protocol can operate "out of the box". > If implementers are free to select their own defaults, the protocol > needs to operate well with any choice of values. If there are > sensible defaults, these need to be stated. > > Indeed, section 3.2 seems to say this. Perhaps a forward reference? > > === > > 3.1. Operations Model > > There may be a need to support a human interface, e.g., for > troubleshooting, and a programmatic interface, e.g., for automated > monitoring and root cause analysis. It might be important that the > internal method routines used by the application programming > interfaces and the human interfaces should be the same to ensure that > data exchanged between these two interfaces is always consistent. > Mixing methods leads to inconsistency, so identifying consistent > methods of retrieving information is relevant. > > This is really sailing too close to the implementation. People > must be free to construct sub-standard and unmarketable > implementations. The IETF is not responsible for making all > implementations successful. The job is to make it possible for > all implementations to be successful given core competences in the > developers. > > I think the furthest a protocol spec RFC could go would be to say > what information must be available to an operator at a human > interface for troubleshooting > > === > > 3.2. Installation and Initial Setup > > In view of the reasons you give why defaults might become out- > dated, you might point out that sometimes it is not advisable to > have defaults. In these cases explicit configuration is required. > > === > > 3.2. Installation and Initial Setup > > Is the text at the top of page 8 supposed to be a bullet list? > > === > > 3.4. Requirements on Other Protocols and Functional Components > > These considerations should generally remain illustrative to avoid > creating restrictions or dependencies, or potentially impacting the > behavior of existing protocols, or restricting the extensibility of > other protocols, or assuming other protocols will not be extended in > certain ways. > > Well, this is quite interesting. > > Suppose you decide to utilise a particular feature of a transport > protocol. You are creating a hard requirement that that feature is > implemented in all implementations of the set {your new protocol, > the transport protocol}. But more importantly, perhaps, you are > requiring that new versions of the transport protocol do not > deprecate the feature you require. > > In short, I don't think you should be too nervous about creating > restrictions or dependencies. If they exist, they must be stated. > > === > > 3.2. Installation and Initial Setup > > For example, the design of Resource ReSerVation Protocol (RSVP) > > I think this example is not well expressed. > > The problem in RSVP was that the IP packet was addressed to the > ultimate RSVP-capable destination, but the RSVP-capable routers > along the path needed to intercept and process the Path message. > This they could only do by "deep packet inspection" or by the > router alert option. > > I wonder whether this example adds significantly to the I-D. > > === > > 4. Management Considerations > > NETCONF addresses this in a generic manner by > > Add citation. > > === > > 4. Management Considerations > > However, debugging on-the-wire interactions is a protocol > issue: it is enormously helpful if a protocol has hooks to make > debugging of network interactions easy, and/or is designed in such a > way that debugging protocol behaviors is easy. Hand-waving this away > is not something that operators like ... > > I think you are including this by hand-waving! > What do you mean by "hooks"? > Surely any protocol can be debugged simply by sniffing it. > If you have specific hooks in mind you must set them out and not > leave the reader guessing. > But if you force the implementation I shall be peeved! > You might, for example, say that there should be alerts issued when > messages are received, or when there are state transitions in the > protocol state machine, but you must recall that: > - the messages can be seen by sniffing > - the state machine is not part of the protocol specification. > This latter point is key. The state machine explains how the > protocol works in order that an implementer can decide how to > react to a received event, but it does not require that the > machine is implemented. > > === > > 4.1. Interoperability > > Interoperability needs to be considered on the syntactic level and > the semantic level. While it can be irritating and time-consuming, > application designers including operators who write their own scripts > can make their processing conditional to accommodate differences > > s/differences/syntactic differences/ ? > > Then, whether the counter is gathered via SNMP or a CLI > command or a SYSLOG message, the counter will have similar meaning. > > "similar"? I think that might not be good enough. Don't you need > "the same"? > > o [RFC3805] - Printer MIB v2 (contains both an IM and a DM > > Missing ")" > > === > > 4.2. Management Information > > I would find it really helpful if you were able to recommend a > language in which to write the information model. Ideally, all > IETF IMs would be in the same language. > > It is important to be able to separately fetch configuration data, > operational state data, and statistics from devices, and to be able > to compare current state to initial state, and to compare data > between devices. > > You seem to have drifted into DMs here. You cannot fetch data from > an IM. It simply explains what data elements exist. In fact, an IM > states all of the data that exists and so there is no confusion. > Confusion can only arise as the DM is constructed and multiple IM > data elements are conflated into single DM objects. > > === > > 4.3. Fault Management > > The protocol designer should document the basic faults and health > indicators that need to be instrumented for the new protocol, and the > alarms and events that must be propagated to management applications > or exposed through a data model. > > Isn't "propagated to management applications" a subset of "exposed > through a data model"? > > The protocol designer should consider how faults information will be > > s/faults/fault/ > > Should the event reporting provide gyaranteed accurate delivery of > s/gyaranteed/guaranteed/ > > === > > 4.3.3. Fault Isolation > > It might be useful to isolate faults, such as a system that emits > malformed messages necessary to coordinate connections properly. > Spanning tree comes to mind. This might be able to be done by > configuring next-hop devices to drop the faulty messages to prevent > them from entering the rest of the network. > > This is not what *I* mean by fault isolation! > Fault isolation is about working out where in the network the fault > is. For example, if end-to-end data delivery is failing (reported by > a notification), fault isolation will find the failed link or node > in the end-to-end path. > > You seem to be describing the process of quarantining faulty > devices. This may also be valuable. > > "Spanning tree comes to mind" is a rather strange sentence without > much context. > > === > > 4.4. Configuration Management > > A protocol desoigners should document what the basic configuration > > s/desoigners/designers/ > > "Requirements for Configuration Management of IP-based Networks" > [RFC3139] discusses requirements for configuration management. > More precisely, > "Requirements for Configuration Management of IP-based Networks" > [RFC3139] discusses requirements for configuration management of > IP-based networks. > Which makes me wonder about the purpose of the sentence :-) > > This document includes... > This document or that document? > > A number of efforts have existed in the IETF to develop policy-based > management. "Terminology for Policy-Based Management" [RFC3198] was > written to standardize the terminology across these efforts. Some of > the efforts resulted in proposals that are NOT RECOMMENDED, so a > protocol designer should check the current recommendation status > before depending on a specific protocol suggestion. > > You have used RFC2119 language, but in section 1.1 you said > This document deliberately does not use the (capitalized) keywords > described in RFC 2119 [RFC2119]. > Furthermore, it is not clear to me whether this I-D is doing the > NOT RECOMMENDing or whether some other RFC has done it. If it is > this I-D, you will need to give reasons. If is some other RFC, you > will need to give references. > > It is highly desirable that text processing tools such as diff, and > version management tools such as RCS or CVS or SVN, can be used to > process configurations. This approach simplifies comparing the > current operational state to the initial configuration. It is > commonplace to compare configuration changes to e.g., last day, last > week, last month, etc. -- having configuration in a text, and human- > understandable format is very valuable for various reasons such as > change control (or verification), configuration consistency checks, > etc. > > Yes, but what has this to do with the protocol design? It might be > related to device implementation. Or it might be relevant to > EMS/NMS implementation. > > As you note in the subsequent paragraph, this may be impossible > even in some text-based DMs. It would certainly be impossible in > an SNMP MIB module. > > To simplify such configuration comparisons, devices should not > arbitrarily reorder data such as access control lists. If a protocol > designer defines mechanisms for configuration, it would be desirable > to standardize the order of elements for consistency of configuration > and of reporting across vendors, and across releases from vendors. > > This example seems a bit specific. And in any case, it is perfectly > possible to sort a list before comparing. > > There are two parts to this: 1. An NMS system could optimize ACLs > for performance reasons 2. Unless the device/NMS systems has correct > rules/a lot of experience, reordering ACLs can lead to a huge > security issue. > > Maybe what you are saying is: > Implementations should not arbitrarily modify configuration data. > In some cases (such as Access Control Lists) the order of data > items is significant and comprises part of the configured data. > > Network wide configurations are ideally stored in central master > databases > > This looks like an unsubstantiated assertion. You might get away > with "Many operators prefer that..." > > It is important to distinguish between the distribution of > configurations and the activation of a certain configuration. > Devices should be able to hold multiple configurations. > > This is really an implementation issue and nothing to do with the > protocol under design. > > Consensus of the 2002 IAB Workshop was that textual configuration > files should be able to contain international characters. > > Do you have a citation? > > These timers may need default values > suggested in the protocol specification and do not need to be > otherwise configurable. > > I had formed the opinion that timers must be given default values > in IETF protocol specifications, but I can't lay my hands on a > reference. > > === > > 4.5. Accounting Management > > A protocol designer should consider whether it would be appropriate > to collect usage information related to this protocol, and if so, > what usage information would be appropriate to collect? > > s/collect?/collect./ > > "Introduction to Accounting Management" [RFC2975] discusses a number > of factors relevant to monitoring usage of protocols for purposes of > capacity and trend analysis, cost allocation, auditing, and billing. > This document also discusses how Remote Authentication Dial In User > This or that? > > Service (RADIUS) [RFC2865], Terminal Access Controller Access Control > System (TACACS) [RFC1492], SNMP, IPFIX, and Packet Sampling (PSAMP) > Protocol [I-D.ietf-psamp-protocol] protocols can be used for these > purposes. > > Surely RFC 2975 does not mention PSAMP? Which makes me wonder what > you are trying to achieve with a list of example protocols. Are > they intended as recommendations (in which case say so and why), > or as a non-exclusive list (in which case a "such as" would be > useful). At the moment it reads like these are your favorites and > you would be upset if someone used a different protocol! > > === > > 4.6. Performance Management > > There are several parts to performance management to be considered: > protocol monitoring, services monitoring, and device monitoring (the > impact of the new protocol/service activation on the device). > > s/services/service/ > > Consider scalability, such as whether performance will be affected by > the number of protocol connections. > > Maybe say "protocol entities" rather than connections? > > > This section seems to flit between the performance of the protocol > under design and the network running the protocol under design, and > the performance of the management of the protocol. Each is > important, but it may be constructive to split them out into > separate sections. The latter will also include a consideration of > how the act of monitoring impacts on network performance. > > > The Benchmarking Methodology WG (bmwg) has defined recommendations > Later you have BMWG. > > === > > 4.7. Security Management > > It must be possible to do consistency checks of access control lists > across devices. Protocol designers should consider information > models to promote comparisons across devices and across vendors to > permit checking the consistency of security configurations. > > I think this "must" is massively excessive! > I would expect each router to have a different access list in the > control plane (a list of its neighbors). Such a mechanism would > actually open up a security vulnerability that has to be protected. > Perhaps you are talking about management plane access lists. This > takes us into the area of securing management activity - see my > comments on Section 7. > > RADIUS and DIAMETER can provide authentication and authorization. A > protocol designer should consider which attributes would be > appropriate for their protocol. > > This paragraph is apropos of what? What are you trying to tell me? > Should I run my management using Radius? Should I try to build > Diameter into my new protocol? > > Different protocols use different assumptions about message security > s/protocols/management protocols/ > > and data access controls. A protocol designer that recommends using > different protocols should consider how security will be applied in a > s/protocols/management protocols/ > > > Although you talk about (presumably management) access lists, I think > I would have expected a discussion of authority levels and policy > with regard to management tasks. > > === > > 7. Security Considerations > > This document is informational and provides guidelines for > considering manageability and operations. It introduces no new > security concerns. > > I think that, although you introduce no new security concerns > directly, you have some things to talk about. > > Firstly, the provision of a management portal to a network device > provides a doorway through which an attack on the device may be > launched. Since you are recommending that the protocol under > development be manageable through the management protocol, you are > requiring that the protocol be vulnerable to a new source of > attacks. Therefore, you must talk about securing the protocol > against these attacks. This might be as simple as saying that only > management protocols with adequate (for some definition of > adequate) security apparatus be used. > > I think it is also of note that a standard description of the > manageable knobs and whistles on a protocol makes it easier for an > attacker to understand what they may try to control and how to > tweak it. > > On the other hand, it would be well worth pointing out that a > well-designed protocol is usually more stable and secure. And that > a protocol that can be managed and inspected offers the operator > a better chance of spotting and quarantining any attacks. > Conversely making a protocol inspectable, is a risk if the wrong > person inspects it! > > If security events cause logs and or notifications/alerts, can > a concerted attack be mounted by causing an excess of these > events? In other words, to the security management mechanisms > constitute the security vulnerability? > > Lastly, the management of security aspects is important, and you > can just reference back to section 4.7. > > === > > 9. Informative References > > I (of course) would favor an informational reference to draft-ietf-pce- > manageability-requirements-06.txt > > === > > [RFC2821] Klensin, J., "Simple Mail Transfer > Protocol", RFC 2821, April 2001. > > I think this has been obsoleted. > > === > > Appendix A. Operations and Management Review Checklist > > Maybe a forward reference to this appendix from sections 1 and 5? > > === > > A.3. Documentation > > Does the proposed protocol have a significant operational impact on > the Internet. If it does, and the document under review targets > standards track, is their enough proof of implementation and/or > operational experience to grant Proposed Standard status? > > Whoah! > > You are going to use this I-D to try to block standards track I-Ds > from becoming RFCs? You are going to get into such a fight!!! > > IMHO this sentence is a complete show-stopper in your I-D. > > (Oh, and s/their/there/) > > === > > Appendix B. Change Log > > Suggest you flag this for removal upon publication as an RFC. > > === > > > Sent: Sunday, January 25, 2009 6:40 PM > > To: opsawg@ietf.org > > Subject: [OPSAWG] (final) WGLC on > > draft-ietf-opsawg-operations-and-management > > > > This is a (hopefully final) WGLC for > > draft-ietf-opsawg-operations-and-management > > there was not enough respose to the last one back in October > > please let the list know what you think of the draft > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From j.schoenwaelder@jacobs-university.de Tue Feb 10 10:31:35 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 58FC73A6CA5 for ; Tue, 10 Feb 2009 10:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_05=-1.11, HELO_EQ_DE=0.35, 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 jb1f-whowRzp for ; Tue, 10 Feb 2009 10:31:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5979D3A6C96 for ; Tue, 10 Feb 2009 10:31:34 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D3F9C001D; Tue, 10 Feb 2009 19:31:37 +0100 (CET) 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 8wZRW-hxe4HT; Tue, 10 Feb 2009 19:31:31 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B46A8C0010; Tue, 10 Feb 2009 19:31:31 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 50B03991C49; Tue, 10 Feb 2009 19:31:30 +0100 (CET) Date: Tue, 10 Feb 2009 19:31:30 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090210183130.GA6147@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "tom.petch" , opsawg@ietf.org References: <20081120200500.GA2973@elstar.local> <000701c98ba3$7ebe4a60$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c98ba3$7ebe4a60$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:31:35 -0000 On Tue, Feb 10, 2009 at 12:31:26PM +0100, tom.petch wrote: > In syslog-msg-mib, is the value of an SD-PARAM stored with or > without the escaping? syslog needs the escapes because of the > syntax of the syslog message, BER.1 does not so they could be > removed. Yes, I consider the escaping of values an encoding issue that is not needed in a MIB module. My proposal is to add the following sentence to the DESCRIPTION of syslogMsgSDParamValue: The value is stored in the unescaped format. And I will add an explicite reference to section 6.3.3 in the SYSLOG specification. Does this solve this issue? /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 Feb 10 10:49:51 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 42BDF3A6971 for ; Tue, 10 Feb 2009 10:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 6W+XFqZFZxOa for ; Tue, 10 Feb 2009 10:49:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BC3E83A6C3C for ; Tue, 10 Feb 2009 10:49:49 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E6C1C001D; Tue, 10 Feb 2009 19:49:49 +0100 (CET) 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 ICUdzyRZtmVN; Tue, 10 Feb 2009 19:49:43 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 907A3C0062; Tue, 10 Feb 2009 19:49:43 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 69ECA991CFC; Tue, 10 Feb 2009 19:49:42 +0100 (CET) Date: Tue, 10 Feb 2009 19:49:42 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20090210184942.GA6263@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Bert Wijnen (IETF)" , opsawg@ietf.org References: <20090210140002.0954628C178@core3.amsl.com> <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:49:51 -0000 On Tue, Feb 10, 2009 at 03:50:54PM +0100, Bert Wijnen (IETF) wrote: > In any event, if you want to stick to DsiplayString, it would > probably be good to explain why this is justified, given the fact > that we DISCOURAGE use of DisplayString these days, I have double checked all uses of DisplayString and now each DESCRIPTION clause has the following notice: The SYSLOG protocol specification constraints this string to printable US-ASCII code points. For most of the protocol fields, I assume the US-ASCII assumption is quite safe. The exceptions are perhaps APP-NAME and perhaps HOSTNAME but this seems to have passed IESG so I should probably not bother. Since the above explanation is not in place, I can also do s/DisplayString/SnmpAdminString/g and perhaps this is actually not such a bad idea for future proofing the MIB module. But then the sentence should probably read "The SYSLOG protocol version 1 specification constraints this string to printable US-ASCII code points"). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From RNATALE@mitre.org Tue Feb 10 10:57:52 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 A91E63A69A2 for ; Tue, 10 Feb 2009 10:57:52 -0800 (PST) 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=[AWL=0.000, 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 HgGwuO+JW9Nb for ; Tue, 10 Feb 2009 10:57:51 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id AC45F3A680F for ; Tue, 10 Feb 2009 10:57:51 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n1AIvso3021365 for ; Tue, 10 Feb 2009 13:57:54 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n1AIvsC7021357; Tue, 10 Feb 2009 13:57:54 -0500 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 10 Feb 2009 13:57:54 -0500 From: "Natale, Bob" To: "j.schoenwaelder@jacobs-university.de" Date: Tue, 10 Feb 2009 13:57:53 -0500 Thread-Topic: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt Thread-Index: AcmLsF74BGxjKaEEQSS7I8XCvmyklQAAMLzw Message-ID: <17969D855F28964C88D177D45B6CDF11020CB47922@IMCMBX2.MITRE.ORG> References: <20090210140002.0954628C178@core3.amsl.com> <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210184942.GA6263@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090210184942.GA6263@elstar.iuhb02.iu-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.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: Tue, 10 Feb 2009 18:57:52 -0000 Hi Juergen, I cannot see any downside to the use of SnmpAdminString vs DispalyString an= d would recommend that change. Cheers, BobN -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Tuesday, February 10, 2009 1:50 PM To: Bert Wijnen (IETF) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt On Tue, Feb 10, 2009 at 03:50:54PM +0100, Bert Wijnen (IETF) wrote: =20 > In any event, if you want to stick to DsiplayString, it would > probably be good to explain why this is justified, given the fact > that we DISCOURAGE use of DisplayString these days, I have double checked all uses of DisplayString and now each DESCRIPTION clause has the following notice: The SYSLOG protocol specification constraints this string =20 to printable US-ASCII code points. For most of the protocol fields, I assume the US-ASCII assumption is quite safe. The exceptions are perhaps APP-NAME and perhaps HOSTNAME but this seems to have passed IESG so I should probably not bother. Since the above explanation is not in place, I can also do s/DisplayString/SnmpAdminString/g and perhaps this is actually not such a bad idea for future proofing the MIB module. But then the sentence should probably read "The SYSLOG protocol version 1 specification constraints this string to printable US-ASCII code points"). /js --=20 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 j.schoenwaelder@jacobs-university.de Tue Feb 10 11:42: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 247D63A6CC8 for ; Tue, 10 Feb 2009 11:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 HwvXz3YGo7zd for ; Tue, 10 Feb 2009 11:42:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 215683A6CC2 for ; Tue, 10 Feb 2009 11:42:28 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F3BFC0066; Tue, 10 Feb 2009 20:42:31 +0100 (CET) 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 69bmqw3aNgJJ; Tue, 10 Feb 2009 20:42:25 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BAC6C0064; Tue, 10 Feb 2009 20:42:25 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 16B6C991E0E; Tue, 10 Feb 2009 20:42:24 +0100 (CET) Date: Tue, 10 Feb 2009 20:42:23 +0100 From: Juergen Schoenwaelder To: "Natale, Bob" Message-ID: <20090210194223.GB6281@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Natale, Bob" , "opsawg@ietf.org" References: <20090210140002.0954628C178@core3.amsl.com> <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210184942.GA6263@elstar.iuhb02.iu-bremen.de> <17969D855F28964C88D177D45B6CDF11020CB47922@IMCMBX2.MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17969D855F28964C88D177D45B6CDF11020CB47922@IMCMBX2.MITRE.ORG> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 19:42:29 -0000 On Tue, Feb 10, 2009 at 01:57:53PM -0500, Natale, Bob wrote: > I cannot see any downside to the use of SnmpAdminString vs > DispalyString and would recommend that change. Yes, but then there are many other constraints coming from the SYSLOG version 1 protocol, like most of the size constraints. Shall I now go ahead and remove them as well since they might change in the future and instead write the size constraints down in the DESCRIPTION clauses? Arguably, for international character sets, some of the sizes are way too short. See, this is a slippery slope... /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 Tue Feb 10 12:02: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 1E11B3A6CCF for ; Tue, 10 Feb 2009 12:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 Fg1c4Am1096q for ; Tue, 10 Feb 2009 12:02:52 -0800 (PST) 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 718A13A6CE6 for ; Tue, 10 Feb 2009 12:01:30 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id ECdx1b0060ldTLk55L1aAL; Tue, 10 Feb 2009 20:01:34 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id EL1a1b0010UQ6dC3QL1abS; Tue, 10 Feb 2009 20:01:34 +0000 From: "David Harrington" To: , "'Bert Wijnen \(IETF\)'" References: <20090210140002.0954628C178@core3.amsl.com><09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210184942.GA6263@elstar.iuhb02.iu-bremen.de> Date: Tue, 10 Feb 2009 15:01:32 -0500 Message-ID: <003401c98bba$5f5936f0$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: AcmLsF5WpDOEBNCTSBOtXkjI7lRGkwACfaUg In-Reply-To: <20090210184942.GA6263@elstar.iuhb02.iu-bremen.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.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: Tue, 10 Feb 2009 20:02:53 -0000 I think this would be a good idea. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, February 10, 2009 1:50 PM > To: Bert Wijnen (IETF) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] I-D > Action:draft-ietf-opsawg-syslog-msg-mib-00.txt > > On Tue, Feb 10, 2009 at 03:50:54PM +0100, Bert Wijnen (IETF) wrote: > > > In any event, if you want to stick to DsiplayString, it would > > probably be good to explain why this is justified, given the fact > > that we DISCOURAGE use of DisplayString these days, > > I have double checked all uses of DisplayString and now each > DESCRIPTION clause has the following notice: > > The SYSLOG protocol specification constraints this string > > to printable US-ASCII code points. > > For most of the protocol fields, I assume the US-ASCII assumption is > quite safe. The exceptions are perhaps APP-NAME and perhaps HOSTNAME > but this seems to have passed IESG so I should probably not bother. > > Since the above explanation is not in place, I can also do > > s/DisplayString/SnmpAdminString/g > > and perhaps this is actually not such a bad idea for future proofing > the MIB module. But then the sentence should probably read "The SYSLOG > protocol version 1 specification constraints this string to printable > US-ASCII code points"). > > /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 randy_presuhn@mindspring.com Tue Feb 10 12:12:41 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 4E3293A6C9D for ; Tue, 10 Feb 2009 12:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.514, 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 SefvIJF-TY3b for ; Tue, 10 Feb 2009 12:12:40 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 604B83A6A99 for ; Tue, 10 Feb 2009 12:12:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RsEDCbRX3/N3InJsKadUdptbv/OHM4jPJ8nNuEQ8is+zq+bDFwVqI0hVv5vr/fV/; 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 [64.105.34.146] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LWyyJ-0007pL-HB for opsawg@ietf.org; Tue, 10 Feb 2009 15:12:43 -0500 Message-ID: <00a001c98bbb$ea497e40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop><20090210154856.GD5949@elstar.iuhb02.iu-bremen.de> <20090210161509.GB6082@elstar.iuhb02.iu-bremen.de> Date: Tue, 10 Feb 2009 12:12:35 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17351a564e436a489bae5b34f3f7c2f7545350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.146 Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString 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, 10 Feb 2009 20:12:41 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Romascanu, Dan (Dan)" > Cc: > Sent: Tuesday, February 10, 2009 8:15 AM > Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString ... > All fine, but in this case, the protocol elements modeled do not > support non ASCII characters and so is there a policy that even in > cases where the protocol is ASCII, DisplayString is DISCOURAGED in > favour of some other string format? To me it seems like a logical consequence of BCP 18 section 3.1, second paragraph: Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text. Randy From ietfdbh@comcast.net Tue Feb 10 12:21:04 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 618583A6A58 for ; Tue, 10 Feb 2009 12:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, 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 7XdEIoEzrks4 for ; Tue, 10 Feb 2009 12:21:02 -0800 (PST) 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 87CD03A6C7E for ; Tue, 10 Feb 2009 12:21:01 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA04.westchester.pa.mail.comcast.net with comcast id EFyR1b07C0SCNGk54LM5dw; Tue, 10 Feb 2009 20:21:05 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id ELM41b00L0UQ6dC3VLM4o9; Tue, 10 Feb 2009 20:21:05 +0000 From: "David Harrington" To: "'tom.petch'" , "'Adrian Farrel'" , References: <5C8D68E9DDC2439B82F3CC0591A54F05@your029b8cecfe> <000801c98ba3$80df0780$0601a8c0@allison> Date: Tue, 10 Feb 2009 15:21:03 -0500 Message-ID: <003601c98bbd$19086470$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: AcmLrBDYOSfamgweT5q5kVZzzbvZbQAEOuiA In-Reply-To: <000801c98ba3$80df0780$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'David B Harrington' , tseely5@gmail.com Subject: Re: [OPSAWG] (final) WGLCondraft-ietf-opsawg-operations-and-management 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, 10 Feb 2009 20:21:04 -0000 Besides the comments form Juergen, Mike, and Adrian, what needs to be done to make this live up to its billing? Do you have explicit recommendations of text? dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of tom.petch > Sent: Tuesday, February 10, 2009 12:05 PM > To: Adrian Farrel; opsawg@ietf.org > Cc: David B Harrington; tseely5@gmail.com > Subject: Re: [OPSAWG] (final) > WGLCondraft-ietf-opsawg-operations-and-management > > I was going to say +1 to Juergen's comments and then I was > going to say +1 to > Mike's comments and then I was going to say +1 to Adrian's > comments and while I > was pondering, ... I left it too late:-( > > But I do echo much of what has been said. I cannot see that > this I-D lives up > to its billing. It is a good idea, and it is good stuff > (give or take some > infelicities of wording, most of which have been pointed out > already) but I do > not see it as good stuff for a working group coming up with a > new protocol, say > an MPLS-TP or sieve or sidr. And that is what I think is > needed. If something > is not designed to be managed ab initio, then it may be > costly, impossible even, > to manage it in the wild. > > Tom Petch > > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: "David B Harrington" ; > > Sent: Wednesday, February 04, 2009 8:54 PM > Subject: Re: [OPSAWG] (final) WGLC > ondraft-ietf-opsawg-operations-and-management > > > > Hi, > > > > Dan asked me to have a look at this which I do primarily > with a routing area > > view on the world. > > > > I'm sorry that I haven't been following this I-D very > closely and apologise > > if you have already discussed and reached conclusion on > some of the points I > > make. > > > > I am largely supportive of this work (see > > draft-ietf-pce-manageability-requirements-06.txt), but I do > have some > > issues. I would be comforted to know that the I-D had had > extensive review > > from within the Ops Area without relying just on my comments! > > > > I would also like to understand how the recommendations > parts of the draft > > will be interpreted by the Ops ADs as they perform IESG > review of I-Ds from > > other areas. Depending on the answer (which I would like to > see encapsulated > > in the document!) I might have other harsher comments about > the content. > > > > More details below. > > > > Cheers, > > Adrian > > > > === > > Title is... > > Guidelines for Considering Operations and Management of > New Protocols > > ...but the Abstract immediately includes... > > New protocols or protocol extensions > > === > > Obviously needs the new IPR boilerplate. > > === > > Abstract line 3 > > s/protocol/protocols/ > > === > > I am somewhat worried by "recommend appropriate standard management > > protocols ... to address the relevant operations and management > > needs." > > > > I understand the theory behind this guidance in terms of making > > equipment that will interwork with management systems, but I > > question its practicality given the vast array of management > > protocols available. And actually, I am not sure that this has a > > direct impact on the success of or development of a protocol. > > > > The introduction says that this "is similar to a WG considering > > which security threats are relevant to their protocol, and then > > recommending appropriate standard security protocols to mitigate > > the relevant threats." I dispute this. The security considerations > > normally make modifications to the protocol under development to > > make it secure, or mandate security features in other protocols > > that the protocol under development uses. But where there is a > > need for an external protocol, this is not usually mandated. For > > example, where key exchange is needed the text will usually say > > something like "may use some form of secure key exchange protocol > > (such as the Internet Key Exchange protocol v2 (IKE) [RFC4306]." > > This is far looser than a recommendation of a specific protocol. > > > > I believe that in practice operators want to go on using the > > management protocols that they already have deployed. If, for > > example, I have deployed routers that I manage using SNMP, I will > > not want to deploy a new routing protocol on those routers if that > > protocol is strongly recommended to be managed using TL1. > > > > Since data modeling is usually tied closely to the protocol used > > for management, it follows from this that developing specific > > data formats (SNMP MIB modules, XML schema, etc.) might also not > > be so very practical. (Arguably we have found this out with MIB > > modules over the last 10 years, but still churn them out.) > > > > What *would* be beneficial, however, is an abstract data model > > for management of the protocol. There are many ways of > > representing the data (XML, BNF, ASN.1, graphical representation, > > etc.) and the Ops Area could usefully pick one and standardise > > it. From there we would have a solid data set that all > > implementations could make available and which separate documents > > could easily map to suitable formats for use by specific > > management protocols. Smart implementers would be able to support > > multiple management protocols with ease. > > > > You do come to this to some extent in section 4.1, and the text > > there seems to be at odds with what you have said in the > > Introduction. > > > > === > > Section 1 > > > > Can you expand "WG" on first usage? > > > > === > > Section 1 > > > > We want to avoid seeming to impose a solution by putting > in place a > > strict terminology - for example implying that a formal > data model, > > or even using a management protocol is mandatory. > > > > > > > > You want to avoid seeming to impose it? > > So, you want to impose it, but you don't want anyone to notice? > > > > > > > > === > > Section 1 > > > > Making a Management Considerations section a mandatory > publication > > requirement for IETF documents is the responsibility of > the IESG, or > > specific area directors, or working groups, and this > document avoids > > recommending any mandatory publication requirements. > > > > I think you may need to go a step further to get this through the > > IESG. It would not be funny to see this paragraph as written, but > > to get a DISCUSS on an I-D from an Ops AD because the I-D did not > > contain a Management Considerations section. > > > > === > > Introduction > > > > We provide some objective criteria to promote interoperability > > > > > > > > There seems to be only one author. Are you royalty? > > Perhaps... "This document provides..." > > > > > > > > === > > Section 1 final line > > > > s/??/?"/ > > > > === > > > > 2.1. IETF Management Framework > > > > For years the IETF has stressed the use of the IETF Standard > > Management Framework and MIB modules [RFC2578] for managing new > > protocols. The IETF designed these to permit multiple > protocols to > > utilize the MIB data [RFC1052], but it became a common > > > > s/became/is/ > > > > === > > > > 3.1. Operations Model > > > > o what are the typical user interfaces - Command line (CLI) or > > graphical user interface (GUI)? > > > > I am not sure that this last item is particularly relevant for a > > large number of the protocols designed in the IETF. We might say > > that the question is valid for a protocol such as FTP, but is it > > relevant for OSPF? Yes, there is a configuration interface to a > > device that runs OSPF, but it is surely nothing to do with the > > protocol design how that interface works. Indeed, you might > > reduce the question to: are the configuration interfaces local or > > remote? But I think you will find that the answer to the question > > is "both" as in the subsequent paragraph. > > > > === > > > > 3.1. Operations Model > > > > Auto-configuration and default parameters might be > > possible for some new protocols. > > > > I would make a much bigger noise about default parameters. There is > > a key question about how the protocol can operate "out of the box". > > If implementers are free to select their own defaults, the protocol > > needs to operate well with any choice of values. If there are > > sensible defaults, these need to be stated. > > > > Indeed, section 3.2 seems to say this. Perhaps a forward reference? > > > > === > > > > 3.1. Operations Model > > > > There may be a need to support a human interface, e.g., for > > troubleshooting, and a programmatic interface, e.g., for > automated > > monitoring and root cause analysis. It might be > important that the > > internal method routines used by the application programming > > interfaces and the human interfaces should be the same > to ensure that > > data exchanged between these two interfaces is always consistent. > > Mixing methods leads to inconsistency, so identifying consistent > > methods of retrieving information is relevant. > > > > This is really sailing too close to the implementation. People > > must be free to construct sub-standard and unmarketable > > implementations. The IETF is not responsible for making all > > implementations successful. The job is to make it possible for > > all implementations to be successful given core competences in the > > developers. > > > > I think the furthest a protocol spec RFC could go would be to say > > what information must be available to an operator at a human > > interface for troubleshooting > > > > === > > > > 3.2. Installation and Initial Setup > > > > In view of the reasons you give why defaults might become out- > > dated, you might point out that sometimes it is not advisable to > > have defaults. In these cases explicit configuration is required. > > > > === > > > > 3.2. Installation and Initial Setup > > > > Is the text at the top of page 8 supposed to be a bullet list? > > > > === > > > > 3.4. Requirements on Other Protocols and Functional Components > > > > These considerations should generally remain > illustrative to avoid > > creating restrictions or dependencies, or potentially > impacting the > > behavior of existing protocols, or restricting the > extensibility of > > other protocols, or assuming other protocols will not be > extended in > > certain ways. > > > > Well, this is quite interesting. > > > > Suppose you decide to utilise a particular feature of a transport > > protocol. You are creating a hard requirement that that feature is > > implemented in all implementations of the set {your new protocol, > > the transport protocol}. But more importantly, perhaps, you are > > requiring that new versions of the transport protocol do not > > deprecate the feature you require. > > > > In short, I don't think you should be too nervous about creating > > restrictions or dependencies. If they exist, they must be stated. > > > > === > > > > 3.2. Installation and Initial Setup > > > > For example, the design of Resource ReSerVation Protocol (RSVP) > > > > I think this example is not well expressed. > > > > The problem in RSVP was that the IP packet was addressed to the > > ultimate RSVP-capable destination, but the RSVP-capable routers > > along the path needed to intercept and process the Path message. > > This they could only do by "deep packet inspection" or by the > > router alert option. > > > > I wonder whether this example adds significantly to the I-D. > > > > === > > > > 4. Management Considerations > > > > NETCONF addresses this in a generic manner by > > > > Add citation. > > > > === > > > > 4. Management Considerations > > > > However, debugging on-the-wire interactions is a protocol > > issue: it is enormously helpful if a protocol has hooks to make > > debugging of network interactions easy, and/or is > designed in such a > > way that debugging protocol behaviors is easy. > Hand-waving this away > > is not something that operators like ... > > > > I think you are including this by hand-waving! > > What do you mean by "hooks"? > > Surely any protocol can be debugged simply by sniffing it. > > If you have specific hooks in mind you must set them out and not > > leave the reader guessing. > > But if you force the implementation I shall be peeved! > > You might, for example, say that there should be alerts issued when > > messages are received, or when there are state transitions in the > > protocol state machine, but you must recall that: > > - the messages can be seen by sniffing > > - the state machine is not part of the protocol specification. > > This latter point is key. The state machine explains how the > > protocol works in order that an implementer can decide how to > > react to a received event, but it does not require that the > > machine is implemented. > > > > === > > > > 4.1. Interoperability > > > > Interoperability needs to be considered on the syntactic > level and > > the semantic level. While it can be irritating and > time-consuming, > > application designers including operators who write > their own scripts > > can make their processing conditional to accommodate differences > > > > s/differences/syntactic differences/ ? > > > > Then, whether the counter is gathered via SNMP or a CLI > > command or a SYSLOG message, the counter will have > similar meaning. > > > > "similar"? I think that might not be good enough. Don't you need > > "the same"? > > > > o [RFC3805] - Printer MIB v2 (contains both an IM and a DM > > > > Missing ")" > > > > === > > > > 4.2. Management Information > > > > I would find it really helpful if you were able to recommend a > > language in which to write the information model. Ideally, all > > IETF IMs would be in the same language. > > > > It is important to be able to separately fetch > configuration data, > > operational state data, and statistics from devices, and > to be able > > to compare current state to initial state, and to compare data > > between devices. > > > > You seem to have drifted into DMs here. You cannot fetch data from > > an IM. It simply explains what data elements exist. In fact, an IM > > states all of the data that exists and so there is no confusion. > > Confusion can only arise as the DM is constructed and multiple IM > > data elements are conflated into single DM objects. > > > > === > > > > 4.3. Fault Management > > > > The protocol designer should document the basic faults and health > > indicators that need to be instrumented for the new > protocol, and the > > alarms and events that must be propagated to management > applications > > or exposed through a data model. > > > > Isn't "propagated to management applications" a subset of "exposed > > through a data model"? > > > > The protocol designer should consider how faults > information will be > > > > s/faults/fault/ > > > > Should the event reporting provide gyaranteed accurate > delivery of > > s/gyaranteed/guaranteed/ > > > > === > > > > 4.3.3. Fault Isolation > > > > It might be useful to isolate faults, such as a system that emits > > malformed messages necessary to coordinate connections properly. > > Spanning tree comes to mind. This might be able to be done by > > configuring next-hop devices to drop the faulty messages > to prevent > > them from entering the rest of the network. > > > > This is not what *I* mean by fault isolation! > > Fault isolation is about working out where in the network the fault > > is. For example, if end-to-end data delivery is failing (reported by > > a notification), fault isolation will find the failed link or node > > in the end-to-end path. > > > > You seem to be describing the process of quarantining faulty > > devices. This may also be valuable. > > > > "Spanning tree comes to mind" is a rather strange sentence without > > much context. > > > > === > > > > 4.4. Configuration Management > > > > A protocol desoigners should document what the basic > configuration > > > > s/desoigners/designers/ > > > > "Requirements for Configuration Management of IP-based Networks" > > [RFC3139] discusses requirements for configuration management. > > More precisely, > > "Requirements for Configuration Management of IP-based Networks" > > [RFC3139] discusses requirements for configuration management of > > IP-based networks. > > Which makes me wonder about the purpose of the sentence :-) > > > > This document includes... > > This document or that document? > > > > A number of efforts have existed in the IETF to develop > policy-based > > management. "Terminology for Policy-Based Management" > [RFC3198] was > > written to standardize the terminology across these > efforts. Some of > > the efforts resulted in proposals that are NOT RECOMMENDED, so a > > protocol designer should check the current recommendation status > > before depending on a specific protocol suggestion. > > > > You have used RFC2119 language, but in section 1.1 you said > > This document deliberately does not use the > (capitalized) keywords > > described in RFC 2119 [RFC2119]. > > Furthermore, it is not clear to me whether this I-D is doing the > > NOT RECOMMENDing or whether some other RFC has done it. If it is > > this I-D, you will need to give reasons. If is some other RFC, you > > will need to give references. > > > > It is highly desirable that text processing tools such > as diff, and > > version management tools such as RCS or CVS or SVN, can > be used to > > process configurations. This approach simplifies comparing the > > current operational state to the initial configuration. It is > > commonplace to compare configuration changes to e.g., > last day, last > > week, last month, etc. -- having configuration in a > text, and human- > > understandable format is very valuable for various > reasons such as > > change control (or verification), configuration > consistency checks, > > etc. > > > > Yes, but what has this to do with the protocol design? It might be > > related to device implementation. Or it might be relevant to > > EMS/NMS implementation. > > > > As you note in the subsequent paragraph, this may be impossible > > even in some text-based DMs. It would certainly be impossible in > > an SNMP MIB module. > > > > To simplify such configuration comparisons, devices should not > > arbitrarily reorder data such as access control lists. > If a protocol > > designer defines mechanisms for configuration, it would > be desirable > > to standardize the order of elements for consistency of > configuration > > and of reporting across vendors, and across releases > from vendors. > > > > This example seems a bit specific. And in any case, it is perfectly > > possible to sort a list before comparing. > > > > There are two parts to this: 1. An NMS system could > optimize ACLs > > for performance reasons 2. Unless the device/NMS > systems has correct > > rules/a lot of experience, reordering ACLs can lead to a huge > > security issue. > > > > Maybe what you are saying is: > > Implementations should not arbitrarily modify configuration data. > > In some cases (such as Access Control Lists) the order of data > > items is significant and comprises part of the configured data. > > > > Network wide configurations are ideally stored in central master > > databases > > > > This looks like an unsubstantiated assertion. You might get away > > with "Many operators prefer that..." > > > > It is important to distinguish between the distribution of > > configurations and the activation of a certain configuration. > > Devices should be able to hold multiple configurations. > > > > This is really an implementation issue and nothing to do with the > > protocol under design. > > > > Consensus of the 2002 IAB Workshop was that textual configuration > > files should be able to contain international characters. > > > > Do you have a citation? > > > > These timers may need default values > > suggested in the protocol specification and do not need to be > > otherwise configurable. > > > > I had formed the opinion that timers must be given default values > > in IETF protocol specifications, but I can't lay my hands on a > > reference. > > > > === > > > > 4.5. Accounting Management > > > > A protocol designer should consider whether it would be > appropriate > > to collect usage information related to this protocol, and if so, > > what usage information would be appropriate to collect? > > > > s/collect?/collect./ > > > > "Introduction to Accounting Management" [RFC2975] > discusses a number > > of factors relevant to monitoring usage of protocols for > purposes of > > capacity and trend analysis, cost allocation, auditing, > and billing. > > This document also discusses how Remote Authentication > Dial In User > > This or that? > > > > Service (RADIUS) [RFC2865], Terminal Access Controller > Access Control > > System (TACACS) [RFC1492], SNMP, IPFIX, and Packet > Sampling (PSAMP) > > Protocol [I-D.ietf-psamp-protocol] protocols can be used > for these > > purposes. > > > > Surely RFC 2975 does not mention PSAMP? Which makes me wonder what > > you are trying to achieve with a list of example protocols. Are > > they intended as recommendations (in which case say so and why), > > or as a non-exclusive list (in which case a "such as" would be > > useful). At the moment it reads like these are your favorites and > > you would be upset if someone used a different protocol! > > > > === > > > > 4.6. Performance Management > > > > There are several parts to performance management to be > considered: > > protocol monitoring, services monitoring, and device > monitoring (the > > impact of the new protocol/service activation on the device). > > > > s/services/service/ > > > > Consider scalability, such as whether performance will > be affected by > > the number of protocol connections. > > > > Maybe say "protocol entities" rather than connections? > > > > > > This section seems to flit between the performance of the protocol > > under design and the network running the protocol under design, and > > the performance of the management of the protocol. Each is > > important, but it may be constructive to split them out into > > separate sections. The latter will also include a consideration of > > how the act of monitoring impacts on network performance. > > > > > > The Benchmarking Methodology WG (bmwg) has defined > recommendations > > Later you have BMWG. > > > > === > > > > 4.7. Security Management > > > > It must be possible to do consistency checks of access > control lists > > across devices. Protocol designers should consider information > > models to promote comparisons across devices and across > vendors to > > permit checking the consistency of security configurations. > > > > I think this "must" is massively excessive! > > I would expect each router to have a different access list in the > > control plane (a list of its neighbors). Such a mechanism would > > actually open up a security vulnerability that has to be protected. > > Perhaps you are talking about management plane access lists. This > > takes us into the area of securing management activity - see my > > comments on Section 7. > > > > RADIUS and DIAMETER can provide authentication and > authorization. A > > protocol designer should consider which attributes would be > > appropriate for their protocol. > > > > This paragraph is apropos of what? What are you trying to tell me? > > Should I run my management using Radius? Should I try to build > > Diameter into my new protocol? > > > > Different protocols use different assumptions about > message security > > s/protocols/management protocols/ > > > > and data access controls. A protocol designer that > recommends using > > different protocols should consider how security will be > applied in a > > s/protocols/management protocols/ > > > > > > Although you talk about (presumably management) access > lists, I think > > I would have expected a discussion of authority levels and policy > > with regard to management tasks. > > > > === > > > > 7. Security Considerations > > > > This document is informational and provides guidelines for > > considering manageability and operations. It introduces no new > > security concerns. > > > > I think that, although you introduce no new security concerns > > directly, you have some things to talk about. > > > > Firstly, the provision of a management portal to a network device > > provides a doorway through which an attack on the device may be > > launched. Since you are recommending that the protocol under > > development be manageable through the management protocol, you are > > requiring that the protocol be vulnerable to a new source of > > attacks. Therefore, you must talk about securing the protocol > > against these attacks. This might be as simple as saying that only > > management protocols with adequate (for some definition of > > adequate) security apparatus be used. > > > > I think it is also of note that a standard description of the > > manageable knobs and whistles on a protocol makes it easier for an > > attacker to understand what they may try to control and how to > > tweak it. > > > > On the other hand, it would be well worth pointing out that a > > well-designed protocol is usually more stable and secure. And that > > a protocol that can be managed and inspected offers the operator > > a better chance of spotting and quarantining any attacks. > > Conversely making a protocol inspectable, is a risk if the wrong > > person inspects it! > > > > If security events cause logs and or notifications/alerts, can > > a concerted attack be mounted by causing an excess of these > > events? In other words, to the security management mechanisms > > constitute the security vulnerability? > > > > Lastly, the management of security aspects is important, and you > > can just reference back to section 4.7. > > > > === > > > > 9. Informative References > > > > I (of course) would favor an informational reference to > draft-ietf-pce- > > manageability-requirements-06.txt > > > > === > > > > [RFC2821] Klensin, J., "Simple > Mail Transfer > > Protocol", RFC 2821, April 2001. > > > > I think this has been obsoleted. > > > > === > > > > Appendix A. Operations and Management Review Checklist > > > > Maybe a forward reference to this appendix from sections 1 and 5? > > > > === > > > > A.3. Documentation > > > > Does the proposed protocol have a significant > operational impact on > > the Internet. If it does, and the document under review targets > > standards track, is their enough proof of implementation and/or > > operational experience to grant Proposed Standard status? > > > > Whoah! > > > > You are going to use this I-D to try to block standards track I-Ds > > from becoming RFCs? You are going to get into such a fight!!! > > > > IMHO this sentence is a complete show-stopper in your I-D. > > > > (Oh, and s/their/there/) > > > > === > > > > Appendix B. Change Log > > > > Suggest you flag this for removal upon publication as an RFC. > > > > === > > > > > Sent: Sunday, January 25, 2009 6:40 PM > > > To: opsawg@ietf.org > > > Subject: [OPSAWG] (final) WGLC on > > > draft-ietf-opsawg-operations-and-management > > > > > > This is a (hopefully final) WGLC for > > > draft-ietf-opsawg-operations-and-management > > > there was not enough respose to the last one back in October > > > please let the list know what you think of the draft > > > > _______________________________________________ > > 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 j.schoenwaelder@jacobs-university.de Tue Feb 10 12:28:50 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 540323A6CC2 for ; Tue, 10 Feb 2009 12:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 RS5MuMUwGtwz for ; Tue, 10 Feb 2009 12:28:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3D4FB3A6CC8 for ; Tue, 10 Feb 2009 12:28:48 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 949CAC0062; Tue, 10 Feb 2009 21:28:51 +0100 (CET) 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 5CaiK0lx6kdp; Tue, 10 Feb 2009 21:28:45 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DCB7C001E; Tue, 10 Feb 2009 21:28:45 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 81904991F02; Tue, 10 Feb 2009 21:28:44 +0100 (CET) Date: Tue, 10 Feb 2009 21:28:44 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20090210202844.GD6281@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Randy Presuhn , opsawg@ietf.org References: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210154856.GD5949@elstar.iuhb02.iu-bremen.de> <20090210161509.GB6082@elstar.iuhb02.iu-bremen.de> <00a001c98bbb$ea497e40$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a001c98bbb$ea497e40$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 20:28:50 -0000 On Tue, Feb 10, 2009 at 12:12:35PM -0800, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Romascanu, Dan (Dan)" > > Cc: > > Sent: Tuesday, February 10, 2009 8:15 AM > > Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString > ... > > All fine, but in this case, the protocol elements modeled do not > > support non ASCII characters and so is there a policy that even in > > cases where the protocol is ASCII, DisplayString is DISCOURAGED in > > favour of some other string format? > > To me it seems like a logical consequence of BCP 18 section 3.1, > second paragraph: > > Protocols MUST be able to use the UTF-8 charset, which consists of > the ISO 10646 coded character set combined with the UTF-8 character > encoding scheme, as defined in [10646] Annex R (published in > Amendment 2), for all text. Here is another quote from BP 18 section 2: Internationalization is for humans. This means that protocols are not subject to internationalization; text strings are. Where protocol elements look like text tokens, such as in many IETF application layer protocols, protocols MUST specify which parts are protocol and which are text. [WR 2.2.1.1] So the question boils down to whether things are protocol elements or text for humans. Since SYSLOG passed all IETF reviews, I as a MIB module author assume things that are not UTF8 must be protocol elements. If this leads to wrong results, I believe someone has to fix the problem SYSLOG has with BCP 18. My point is that blindly discouraging DisplayString in favour of SnmpAdminString or Utf8String without taking the context into account (whether something is a protocol element or text) is not mandated by BCP 18 section 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 ietfdbh@comcast.net Tue Feb 10 12:37: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 2C83C3A6828 for ; Tue, 10 Feb 2009 12:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 ZYtRYqStsoch for ; Tue, 10 Feb 2009 12:36:58 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id A67823A684F for ; Tue, 10 Feb 2009 12:36:58 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA07.westchester.pa.mail.comcast.net with comcast id EJkb1b0060QuhwU57Ld2nc; Tue, 10 Feb 2009 20:37:02 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id ELd11b00N0UQ6dC3NLd1CT; Tue, 10 Feb 2009 20:37:02 +0000 From: "David Harrington" To: , "'Natale, Bob'" References: <20090210140002.0954628C178@core3.amsl.com><09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop><20090210184942.GA6263@elstar.iuhb02.iu-bremen.de><17969D855F28964C88D177D45B6CDF11020CB47922@IMCMBX2.MITRE.ORG> <20090210194223.GB6281@elstar.iuhb02.iu-bremen.de> Date: Tue, 10 Feb 2009 15:37:00 -0500 Message-ID: <003701c98bbf$53bd9e80$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: AcmLt7nYfxjZPcN3SfW6DCTZ5ssqMQABI4yw In-Reply-To: <20090210194223.GB6281@elstar.iuhb02.iu-bremen.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.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: Tue, 10 Feb 2009 20:37:00 -0000 Hi Juergen, If I understand correctly, ASCII is a subset of UTF-8. So I see no problem bringing the USASCII elements of the syslog message into a UTF-8 object. Do you intend to take the UTF-8 MIB objects and convert them into syslog messages? dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, February 10, 2009 2:42 PM > To: Natale, Bob > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] I-D > Action:draft-ietf-opsawg-syslog-msg-mib-00.txt > > On Tue, Feb 10, 2009 at 01:57:53PM -0500, Natale, Bob wrote: > > > I cannot see any downside to the use of SnmpAdminString vs > > DispalyString and would recommend that change. > > Yes, but then there are many other constraints coming from the SYSLOG > version 1 protocol, like most of the size constraints. Shall I now go > ahead and remove them as well since they might change in the future > and instead write the size constraints down in the DESCRIPTION > clauses? Arguably, for international character sets, some of the sizes > are way too short. See, this is a slippery slope... > > /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 j.schoenwaelder@jacobs-university.de Tue Feb 10 13:08:27 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 164DC3A6CF0 for ; Tue, 10 Feb 2009 13:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 cSrsaeoIKTKg for ; Tue, 10 Feb 2009 13:08:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C5FBD28C0DF for ; Tue, 10 Feb 2009 13:08:25 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BC30C006D; Tue, 10 Feb 2009 22:08:29 +0100 (CET) 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 TsxTAHiSlzKw; Tue, 10 Feb 2009 22:08:22 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7E78C0064; Tue, 10 Feb 2009 22:08:22 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id B9801991FC5; Tue, 10 Feb 2009 22:08:21 +0100 (CET) Date: Tue, 10 Feb 2009 22:08:21 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090210210821.GE6281@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , "'Natale, Bob'" , opsawg@ietf.org References: <20090210140002.0954628C178@core3.amsl.com> <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210184942.GA6263@elstar.iuhb02.iu-bremen.de> <17969D855F28964C88D177D45B6CDF11020CB47922@IMCMBX2.MITRE.ORG> <20090210194223.GB6281@elstar.iuhb02.iu-bremen.de> <003701c98bbf$53bd9e80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003701c98bbf$53bd9e80$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "'Natale, Bob'" , opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 21:08:27 -0000 On Tue, Feb 10, 2009 at 03:37:00PM -0500, David Harrington wrote: > If I understand correctly, ASCII is a subset of UTF-8. > So I see no problem bringing the USASCII elements of the syslog > message into a UTF-8 object. > > Do you intend to take the UTF-8 MIB objects and convert them into > syslog messages? Here is the story again (exclusing meta discussion of DisplayString policies and BCP 18): - The current SYSLOG protocol says its US-ASCII. - I thought DisplayString would be an appropriate type. - It was suggested to not use DisplayString because DisplayString isn't a great idea anymore. - I said there is no difference since the protocol says it is US-ASCII and the only imaginable benefit to move to SnmpAdminString is an attempt to future proof the MIB module in case a future SYSLOG version allows UTF8. - I noted that in case SYSLOG version N with N > 1 makes some of the US-ASCII protocol elements UTF8, then likely some of the size restrictions need to change as well and I asked whether I should drop size the restrictions from the MIB as well in order to future proof the MIB even more. While this may sound polemic (and to some extend it is), there is some truth here since the number of bytes needed in UTF8 to encoded characters is not "fairly" distributed over the scripts out there. For example, the Euro symbol costs three bytes while the US dollar is comparably cheap with just one byte. I guess for moving forward, I should simply change all DisplayStrings to SnmpAdminStrings and then the DESCRIPTION clause says for SYSLOG version 1, this is US-ASCII - this way I hope no policy questions will be asked anymore. /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 Feb 10 13:23:46 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 E513428C1E8 for ; Tue, 10 Feb 2009 13:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 cRIeXsMxgtMt for ; Tue, 10 Feb 2009 13:23:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 796643A6B8B for ; Tue, 10 Feb 2009 13:23:45 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE873C0062; Tue, 10 Feb 2009 22:23:48 +0100 (CET) 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 5USY0+WfqBR2; Tue, 10 Feb 2009 22:23:42 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7251CC0068; Tue, 10 Feb 2009 22:23:42 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 7A48F9920A2; Tue, 10 Feb 2009 22:23:41 +0100 (CET) Date: Tue, 10 Feb 2009 22:23:41 +0100 From: Juergen Schoenwaelder To: David Harrington , "'Natale, Bob'" , opsawg@ietf.org Message-ID: <20090210212341.GA6475@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Harrington , "'Natale, Bob'" , opsawg@ietf.org References: <20090210140002.0954628C178@core3.amsl.com> <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop> <20090210184942.GA6263@elstar.iuhb02.iu-bremen.de> <17969D855F28964C88D177D45B6CDF11020CB47922@IMCMBX2.MITRE.ORG> <20090210194223.GB6281@elstar.iuhb02.iu-bremen.de> <003701c98bbf$53bd9e80$0600a8c0@china.huawei.com> <20090210210821.GE6281@elstar.iuhb02.iu-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090210210821.GE6281@elstar.iuhb02.iu-bremen.de> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 21:23:47 -0000 On Tue, Feb 10, 2009 at 10:08:21PM +0100, Juergen Schoenwaelder wrote: > On Tue, Feb 10, 2009 at 03:37:00PM -0500, David Harrington wrote: > > > If I understand correctly, ASCII is a subset of UTF-8. > > So I see no problem bringing the USASCII elements of the syslog > > message into a UTF-8 object. > > > > Do you intend to take the UTF-8 MIB objects and convert them into > > syslog messages? > > Here is the story again (exclusing meta discussion of DisplayString > policies and BCP 18): > > - The current SYSLOG protocol says its US-ASCII. > > - I thought DisplayString would be an appropriate type. > > - It was suggested to not use DisplayString because DisplayString > isn't a great idea anymore. > > - I said there is no difference since the protocol says it is US-ASCII > and the only imaginable benefit to move to SnmpAdminString is an > attempt to future proof the MIB module in case a future SYSLOG > version allows UTF8. > > - I noted that in case SYSLOG version N with N > 1 makes some of the > US-ASCII protocol elements UTF8, then likely some of the size > restrictions need to change as well and I asked whether I should > drop size the restrictions from the MIB as well in order to future > proof the MIB even more. While this may sound polemic (and to some > extend it is), there is some truth here since the number of bytes > needed in UTF8 to encoded characters is not "fairly" distributed > over the scripts out there. For example, the Euro symbol costs three > bytes while the US dollar is comparably cheap with just one byte. > > I guess for moving forward, I should simply change all DisplayStrings > to SnmpAdminStrings and then the DESCRIPTION clause says for SYSLOG > version 1, this is US-ASCII - this way I hope no policy questions will > be asked anymore. Let me add that the SYSLOG extensibility mechanism are structured data elements. So if APP-NAME or HOSTNAME is broken, the likely way to fix this is to introduce and SD-ELEM that carries values in a more suitable representation. Note that this works because PARAM-VALUE is a UTF-8-STRING in the protocol and syslogMsgSDParamValue is an SnmpAdminString in the MIB module. So my conclusion for today before I catch some sleep is that the DisplayStrings are fine and since I added an explanation that they are consistent with the protocol, I think we are done. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Tue Feb 10 13:37:35 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 1458D3A6852 for ; Tue, 10 Feb 2009 13:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 k2nozyg8KLGJ for ; Tue, 10 Feb 2009 13:37:34 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id A59C53A6A70 for ; Tue, 10 Feb 2009 13:37:33 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LX0IP-0002D5-Te; Tue, 10 Feb 2009 22:37:34 +0100 Message-ID: <3DFCA19514414F1CBF65A64381CCD834@BertLaptop> From: "Bert Wijnen \(IETF\)" To: , "Randy Presuhn" References: <09F1D9C69F6A4DAF843E6781DDD72303@BertLaptop><20090210154856.GD5949@elstar.iuhb02.iu-bremen.de><20090210161509.GB6082@elstar.iuhb02.iu-bremen.de><00a001c98bbb$ea497e40$6801a8c0@oemcomputer> <20090210202844.GD6281@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090210202844.GD6281@elstar.iuhb02.iu-bremen.de> Date: Tue, 10 Feb 2009 22:14:15 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03BD_01C98BCC.E8D481C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString 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, 10 Feb 2009 21:37:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03BD_01C98BCC.E8D481C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As I said in my original comment. It is quite possiblke that we = "justify" using DisplayStrings ebcause the underlying data is just that subset of ASCII. That I can = live with. I would like to see some text somehwere that describes that justification. So that if/wehen = we review other MIB modules where we challenge the use of DisplayString that we = can expalibn why it was/is ok in the Syslog-MIB. Bert ----- Original Message -----=20 From: Juergen Schoenwaelder=20 To: Randy Presuhn=20 Cc: opsawg@ietf.org=20 Sent: Tuesday, February 10, 2009 9:28 PM Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString On Tue, Feb 10, 2009 at 12:12:35PM -0800, Randy Presuhn wrote: > Hi - >=20 > > From: "Juergen Schoenwaelder" = > > To: "Romascanu, Dan (Dan)" > > Cc: > > Sent: Tuesday, February 10, 2009 8:15 AM > > Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs = SnmpAdminString > ... > > All fine, but in this case, the protocol elements modeled do not > > support non ASCII characters and so is there a policy that even in > > cases where the protocol is ASCII, DisplayString is DISCOURAGED in > > favour of some other string format? >=20 > To me it seems like a logical consequence of BCP 18 section 3.1, > second paragraph: >=20 > Protocols MUST be able to use the UTF-8 charset, which consists = of > the ISO 10646 coded character set combined with the UTF-8 = character > encoding scheme, as defined in [10646] Annex R (published in > Amendment 2), for all text. Here is another quote from BP 18 section 2: Internationalization is for humans. This means that protocols are = not subject to internationalization; text strings are. Where protocol elements look like text tokens, such as in many IETF application layer protocols, protocols MUST specify which parts are protocol = and which are text. [WR 2.2.1.1] So the question boils down to whether things are protocol elements or text for humans. Since SYSLOG passed all IETF reviews, I as a MIB module author assume things that are not UTF8 must be protocol elements. If this leads to wrong results, I believe someone has to fix the problem SYSLOG has with BCP 18. My point is that blindly discouraging DisplayString in favour of SnmpAdminString or Utf8String without taking the context into account (whether something is a protocol element or text) is not mandated by BCP 18 section 2. /js --=20 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 ------=_NextPart_000_03BD_01C98BCC.E8D481C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As I said in my original comment. It is quite = possiblke that=20 we "justify" using DisplayStrings
ebcause the underlying data is just that subset of = ASCII. That=20 I can live with. I would like to see
some text somehwere that describes that = justification. So that=20 if/wehen we review
other MIB modules where we challenge the use of = DisplayString=20 that we can expalibn
why it was/is ok in the Syslog-MIB.
 
Bert
 
----- Original Message -----
From:=20 Juergen = Schoenwaelder=20
Sent: Tuesday, February 10, = 2009 9:28=20 PM
Subject: Re: [OPSAWG] = SYSLOG-MSG-MIB:=20 DisplayString vs SnmpAdminString

On Tue, Feb 10, 2009 at 12:12:35PM -0800, Randy Presuhn = wrote:
> Hi -
>
> > From: "Juergen = Schoenwaelder" <j.schoenwaelder@jaco= bs-university.de>
>=20 > To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
> = > Cc:=20 <opsawg@ietf.org>
> = >=20 Sent: Tuesday, February 10, 2009 8:15 AM
> > Subject: Re: = [OPSAWG]=20 SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString
> ...
> = > All=20 fine, but in this case, the protocol elements modeled do not
> = >=20 support non ASCII characters and so is there a policy that even = in
>=20 > cases where the protocol is ASCII, DisplayString is DISCOURAGED=20 in
> > favour of some other string format?
>
> = To me it=20 seems like a logical consequence of BCP 18 section 3.1,
> second = paragraph:
>
>    Protocols MUST be able = to use=20 the UTF-8 charset, which consists of
>    the ISO = 10646=20 coded character set combined with the UTF-8=20 character
>    encoding scheme, as defined in = [10646]=20 Annex R (published in
>    Amendment 2), for all=20 text.

Here is another quote from BP 18 section = 2:

  =20 Internationalization is for humans. This means that protocols are=20 not
   subject to internationalization; text strings are. = Where=20 protocol
   elements look like text tokens, such as in = many IETF=20 application
   layer protocols, protocols MUST specify = which=20 parts are protocol and
   which are text. [WR = 2.2.1.1]

So=20 the question boils down to whether things are protocol elements = or
text for=20 humans. Since SYSLOG passed all IETF reviews, I as a MIB
module = author=20 assume things that are not UTF8 must be protocol
elements. If this = leads to=20 wrong results, I believe someone has to fix
the problem SYSLOG has = with BCP=20 18.

My point is that blindly discouraging DisplayString in = favour=20 of
SnmpAdminString or Utf8String without taking the context into=20 account
(whether something is a protocol element or text) is not = mandated=20 by
BCP 18 section 2.

/js

--
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring 1, = 28759=20 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
_______________________________________________
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg
------=_NextPart_000_03BD_01C98BCC.E8D481C0-- From cfinss@dial.pipex.com Wed Feb 11 08:35:17 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 4F97B3A6B90 for ; Wed, 11 Feb 2009 08:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 ALXAg4ZtuJPu for ; Wed, 11 Feb 2009 08:35:16 -0800 (PST) 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 4C3553A6A9C for ; Wed, 11 Feb 2009 08:35:16 -0800 (PST) X-Trace: 75511235/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.112/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.112 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: Aq8EAIuMkkk+vGlw/2dsb2JhbACDRkWKCrdNCY9CAQaCXIE3Bg X-IronPort-AV: E=Sophos;i="4.38,193,1233532800"; d="scan'208";a="75511235" X-IP-Direction: IN Received: from 1cust112.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.112]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Feb 2009 16:35:17 +0000 Message-ID: <054c01c98c5e$31e25220$0601a8c0@allison> From: "tom.petch" To: References: <20081120200500.GA2973@elstar.local> <000701c98ba3$7ebe4a60$0601a8c0@allison> <20090210183130.GA6147@elstar.iuhb02.iu-bremen.de> Date: Wed, 11 Feb 2009 12:01:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents 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: Wed, 11 Feb 2009 16:35:17 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: Sent: Tuesday, February 10, 2009 7:31 PM Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents > On Tue, Feb 10, 2009 at 12:31:26PM +0100, tom.petch wrote: > > > In syslog-msg-mib, is the value of an SD-PARAM stored with or > > without the escaping? syslog needs the escapes because of the > > syntax of the syslog message, BER.1 does not so they could be > > removed. > > Yes, I consider the escaping of values an encoding issue that is not > needed in a MIB module. My proposal is to add the following sentence > to the DESCRIPTION of syslogMsgSDParamValue: > > The value is stored in the unescaped format. > > And I will add an explicite reference to section 6.3.3 in the SYSLOG > specification. Does this solve this issue? > Yes, that fixes it Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Wed Feb 11 23:59: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 9B42B3A6930 for ; Wed, 11 Feb 2009 23:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 qDbbU-10p7r1 for ; Wed, 11 Feb 2009 23:59:23 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id C3C613A6850 for ; Wed, 11 Feb 2009 23:59:23 -0800 (PST) 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 <0KEY002NG0V1BV30@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 12 Feb 2009 15:59:27 +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 <0KEY003MN0UZ8Q00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 12 Feb 2009 15:59:25 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 12 Feb 2009 15:59:23 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 12 Feb 2009 15:59:23 +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 Cc: opsawg@ietf.org Subject: [OPSAWG] sec 9, syslog-msg-mib-00. 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, 12 Feb 2009 07:59:24 -0000 Hi, bullet 1: "Unauthorized modifications may either cause increased memory consumption or turn off the capability to retrieve notifications using GET class operations." In what case, a attack could turn off the capability to use GET? Could you elaborate it? bullet 2: "Unauthorized modifications to enable notification generation may be used as part of a denial of service attack against a network management system if for exampe the syslog server accepts unauthorized syslog messages." Does 'syslog server' refer to 'syslog-to-snmp converter'? Do you mean many unauthorized syslog messages are converted to SNMP notification to be sent out in this case? Thanks, Washam From j.schoenwaelder@jacobs-university.de Thu Feb 12 01:03:32 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 DAA143A6ABA for ; Thu, 12 Feb 2009 01:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.372, 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 Wv-Xyeqqy-85 for ; Thu, 12 Feb 2009 01:03:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BF4AA3A6930 for ; Thu, 12 Feb 2009 01:03:31 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6006C0005; Thu, 12 Feb 2009 10:03:36 +0100 (CET) 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 GBwQRfeVcu4c; Thu, 12 Feb 2009 10:03:29 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A704CC0022; Thu, 12 Feb 2009 10:03:29 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id A475499391B; Thu, 12 Feb 2009 10:03:28 +0100 (CET) Date: Thu, 12 Feb 2009 10:03:28 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090212090328.GB8533@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , opsawg@ietf.org References: 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] sec 9, syslog-msg-mib-00. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 09:03:32 -0000 On Thu, Feb 12, 2009 at 03:59:23PM +0800, WashamFan wrote: > Hi, > > bullet 1: > "Unauthorized modifications may either cause increased > memory consumption or turn off the capability to > retrieve notifications using GET class operations." > > In what case, a attack could turn off the capability to > use GET? Could you elaborate it? Here is the full quote: o syslogMsgTableMaxSize: This object controls how many entries are kept in the syslogMsgTable. Unauthorized modifications may either cause increased memory consumption or turn off the capability to retrieve notifications using GET class operations. This be used to hide traces of an attack. If you look at the definition of syslogMsgTableMaxSize, it should be obvious that setting this to 0 means not cache of syslog messages exists. Do you think this is not obvious? OK, since you asked, I will try to explain this better. > bullet 2: > "Unauthorized modifications to enable > notification generation may be used as part of a denial of service > attack against a network management system if for exampe the > syslog server accepts unauthorized syslog messages." > > Does 'syslog server' refer to 'syslog-to-snmp converter'? > Do you mean many unauthorized syslog messages are converted > to SNMP notification to be sent out in this case? Yes, I will s/syslog server/SYSLOG to SNMP converter/ here and fix the spelling of example. /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 Thu Feb 12 02:32:10 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 84B523A6B32 for ; Thu, 12 Feb 2009 02:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Ouz0e1ytMjFt for ; Thu, 12 Feb 2009 02:32:09 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 940B13A6B22 for ; Thu, 12 Feb 2009 02:32:09 -0800 (PST) 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 <0KEY00MMD7XOLG40@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 12 Feb 2009 18:32:12 +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 <0KEY00H5O7XO7V10@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 12 Feb 2009 18:32:12 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 12 Feb 2009 18:32:12 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 12 Feb 2009 18:32:12 +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: <20090212090328.GB8533@elstar.iuhb02.iu-bremen.de> References: <20090212090328.GB8533@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] sec 9, syslog-msg-mib-00. 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, 12 Feb 2009 10:32:10 -0000 > On Thu, Feb 12, 2009 at 03:59:23PM +0800, WashamFan wrote: > > Hi, > > > > bullet 1: > > "Unauthorized modifications may either cause increased > > memory consumption or turn off the capability to > > retrieve notifications using GET class operations." > > > > In what case, a attack could turn off the capability to > > use GET? Could you elaborate it? > > Here is the full quote: > > o syslogMsgTableMaxSize: This object controls how many entries are > kept in the syslogMsgTable. Unauthorized modifications may either > cause increased memory consumption or turn off the capability to > retrieve notifications using GET class operations. This be used > to hide traces of an attack. > > If you look at the definition of syslogMsgTableMaxSize, it should be > obvious that setting this to 0 means not cache of syslog messages > exists. Do you think this is not obvious? OK, since you asked, I will > try to explain this better. Maybe this is obvious to some people, I am not sure. But, It would help if you explain this better, I think. Washam From ietfdbh@comcast.net Thu Feb 12 07:07:45 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 B9D763A68A1 for ; Thu, 12 Feb 2009 07:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=1.848, 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 OG+AKL5D3pQ9 for ; Thu, 12 Feb 2009 07:07:39 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id A61EF3A6BAF for ; Thu, 12 Feb 2009 07:07:39 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Ez201b0020SCNGk5137XmN; Thu, 12 Feb 2009 15:07:31 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id F37l1b0080UQ6dC3V37l9w; Thu, 12 Feb 2009 15:07:46 +0000 From: "David Harrington" To: , "'WashamFan'" References: <20090212090328.GB8533@elstar.iuhb02.iu-bremen.de> Date: Thu, 12 Feb 2009 10:07:44 -0500 Message-ID: <009401c98d23$a8ad20e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090212090328.GB8533@elstar.iuhb02.iu-bremen.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmM8M06SGLv8ktoQ8OBXGVmjudwbAAMrC0A Cc: opsawg@ietf.org Subject: Re: [OPSAWG] sec 9, syslog-msg-mib-00. 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, 12 Feb 2009 15:07:45 -0000 Hi, >From the wording you used, I didn't find that obvious either. s/This be/This can be/ dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Thursday, February 12, 2009 4:03 AM > To: WashamFan > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] sec 9, syslog-msg-mib-00. > > On Thu, Feb 12, 2009 at 03:59:23PM +0800, WashamFan wrote: > > Hi, > > > > bullet 1: > > "Unauthorized modifications may either cause increased > > memory consumption or turn off the capability to > > retrieve notifications using GET class operations." > > > > In what case, a attack could turn off the capability to > > use GET? Could you elaborate it? > > Here is the full quote: > > o syslogMsgTableMaxSize: This object controls how many entries are > kept in the syslogMsgTable. Unauthorized modifications > may either > cause increased memory consumption or turn off the capability to > retrieve notifications using GET class operations. This be used > to hide traces of an attack. > > If you look at the definition of syslogMsgTableMaxSize, it should be > obvious that setting this to 0 means not cache of syslog messages > exists. Do you think this is not obvious? OK, since you asked, I will > try to explain this better. > > > bullet 2: > > "Unauthorized modifications to enable > > notification generation may be used as part of a denial > of service > > attack against a network management system if for exampe the > > syslog server accepts unauthorized syslog messages." > > > > Does 'syslog server' refer to 'syslog-to-snmp converter'? > > Do you mean many unauthorized syslog messages are converted > > to SNMP notification to be sent out in this case? > > Yes, I will s/syslog server/SYSLOG to SNMP converter/ here and fix the > spelling of example. > > /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 root@core3.amsl.com Mon Feb 16 13:00:01 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 395B63A6D0C; Mon, 16 Feb 2009 13:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090216210001.395B63A6D0C@core3.amsl.com> Date: Mon, 16 Feb 2009 13:00:01 -0800 (PST) Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-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: Mon, 16 Feb 2009 21:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Author(s) : J. Schoenwaelder, et al. Filename : draft-ietf-opsawg-syslog-msg-mib-01.txt Pages : 21 Date : 2009-02-16 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsawg-syslog-msg-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-16124959.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Mon Feb 16 13:52: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 4250F3A6807 for ; Mon, 16 Feb 2009 13:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, 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 ZOMOhHdmdiCL for ; Mon, 16 Feb 2009 13:52:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3B5263A6842 for ; Mon, 16 Feb 2009 13:52:02 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54820C0010 for ; Mon, 16 Feb 2009 22:52:12 +0100 (CET) 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 j2Vcs+Q6JgD9; Mon, 16 Feb 2009 22:52:07 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14278C00C2; Mon, 16 Feb 2009 22:52:07 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 08A769A2C83; Mon, 16 Feb 2009 22:52:05 +0100 (CET) Date: Mon, 16 Feb 2009 22:52:05 +0100 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20090216215205.GA5714@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: opsawg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [OPSAWG] syslog-msg-mib-01 (and syslog-snmp-00) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 21:52:03 -0000 Hi, I have posed an update of the SYSLOG-MSG-MIB document to address the comments received on the mailing list. I believe the document is technically complete and ready to be last called so that we get even more reviews and can try to resolve any issues before the next IETF. To make reviews efficient, it might also be a good idea to last call both syslog mapping documents together: draft-ietf-opsawg-syslog-msg-mib-01.txt draft-ietf-opsawg-syslog-snmp-00.txt /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 Tue Feb 17 23:21:59 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 9347C28C181 for ; Tue, 17 Feb 2009 23:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001] 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 VISmzOcTm0G8 for ; Tue, 17 Feb 2009 23:21:58 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id A6CAB3A6980 for ; Tue, 17 Feb 2009 23:21:58 -0800 (PST) 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.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KF900CCH34SHM70@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 18 Feb 2009 15:22:06 +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 <0KF900MIG34R7300@hstml02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 18 Feb 2009 15:22:04 +0800 (CST) Received: from [10.27.142.196] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 18 Feb 2009 15:22:03 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Wed, 18 Feb 2009 15:22:03 +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 Cc: opsawg@ietf.org Subject: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 18 Feb 2009 07:21:59 -0000 Hi, I found that syslogMsgSDTable can not exactly tell the position of parameters in SDE. E.g., [sd-id para="1" value="1" para="2" value="2"] syslogMsgSDTable can tell para="1" is before para="2" and value="1" is before value="2" according to syslogMsgSDParamIndex, but can not tell value="1" position between para="1" and para="2". Think about how to represent snmp SDE defined in your another draft in syslogMsgSDTable, there is the same concern. I am not sure if you have considered it. What do you think of it? BTW: Why mark 'syslogMsgSDElementName', 'syslogMsgSDParamName', 'syslogMsgParamIndex' as 'not-accessible', you don't want user to read them? a typo: page12 : "syslogMsgSDParamIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This objects indexes the instance of a structured data element that occurs multiple times in a structured data element, starting from 1. For parameters that only occure once, the value of this object is 1." REFERENCE "RFCYYYY: The syslog Protocol (section 6.3.3)" ::= { syslogMsgSDEntry 3 }" s/the instance of a structured data element/the instance of a parameter/ washam From j.schoenwaelder@jacobs-university.de Tue Feb 17 23:50:21 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 6BFAE3A6920 for ; Tue, 17 Feb 2009 23:50:21 -0800 (PST) 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 bhGk7rXVoGZS for ; Tue, 17 Feb 2009 23:50:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 579A33A68DD for ; Tue, 17 Feb 2009 23:50:20 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAE04C0102; Wed, 18 Feb 2009 08:50:31 +0100 (CET) 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 X5XZZWQ9u7nX; Wed, 18 Feb 2009 08:50:26 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01349C010B; Wed, 18 Feb 2009 08:50:26 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id D2B0F9A4D6A; Wed, 18 Feb 2009 08:50:24 +0100 (CET) Date: Wed, 18 Feb 2009 08:50:24 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , opsawg@ietf.org References: 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] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 07:50:21 -0000 On Wed, Feb 18, 2009 at 03:22:03PM +0800, WashamFan wrote: > I found that syslogMsgSDTable can not exactly tell > the position of parameters in SDE. E.g., > > [sd-id para="1" value="1" para="2" value="2"] > > syslogMsgSDTable can tell para="1" is before > para="2" and value="1" is before value="2" according > to syslogMsgSDParamIndex, but can not tell value="1" > position between para="1" and para="2". The SYSLOG specification says: SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 So [sd-id para="1" para="2" value="1" value="2"] just does not make sense in SYSLOG. I do not see the problem. > Think about how to represent snmp SDE defined in your > another draft in syslogMsgSDTable, there is the same > concern. I do not see the problem. Please give me an example where things do not work. > BTW: Why mark 'syslogMsgSDElementName', 'syslogMsgSDParamName', > 'syslogMsgParamIndex' as 'not-accessible', you don't want user > to read them? This is how SMIv2 works (RFC 2578 section 7.7). You read auxilliary objects by unpacking the instance identifier. > a typo: page12 : > "syslogMsgSDParamIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..4294967295) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This objects indexes the instance of a structured data element > that occurs multiple times in a structured data element, > starting from 1. For parameters that only occure once, the > value of this object is 1." > REFERENCE > "RFCYYYY: The syslog Protocol (section 6.3.3)" > ::= { syslogMsgSDEntry 3 }" > s/the instance of a structured data element/the instance of a parameter/ Good catch - I will fix this. /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 Feb 18 01:09: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 944C128C1E2 for ; Wed, 18 Feb 2009 01:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.805, 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 b8vpx2AIJV3v for ; Wed, 18 Feb 2009 01:09:08 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 8A71628C1E1 for ; Wed, 18 Feb 2009 01:09:08 -0800 (PST) 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.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KF900CEK83DHM80@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 18 Feb 2009 17:09:15 +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 <0KF900MRL83BLT00@hstml02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 18 Feb 2009 17:09:13 +0800 (CST) Received: from [10.27.142.196] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 18 Feb 2009 17:09:11 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Wed, 18 Feb 2009 17:09:11 +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: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 18 Feb 2009 09:09:09 -0000 > On Wed, Feb 18, 2009 at 03:22:03PM +0800, WashamFan wrote: > > > I found that syslogMsgSDTable can not exactly tell > > the position of parameters in SDE. E.g., > > > > [sd-id para="1" value="1" para="2" value="2"] > > > > syslogMsgSDTable can tell para="1" is before > > para="2" and value="1" is before value="2" according > > to syslogMsgSDParamIndex, but can not tell value="1" > > position between para="1" and para="2". > > The SYSLOG specification says: > > SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 > > So [sd-id para="1" para="2" value="1" value="2"] just does not make > sense in SYSLOG. I do not see the problem. > > > Think about how to represent snmp SDE defined in your > > another draft in syslogMsgSDTable, there is the same > > concern. > > I do not see the problem. Please give me an example where things do > not work. Below is syslog messages from page10, syslog-snmp-00: <29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47 [snmp ctxEngine="800002b804616263" ctxName="ctx1" v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" v="1.3.6.1.2.1.2.2.1.1.3" d="3" v="1.3.6.1.2.1.2.2.1.7.3" d="1" v="1.3.6.1.2.1.2.2.1.8.3" d="1"] I assume the corresponding entries in syslogMsgSDTable: syslogMsgIndex.1 = 1 ... syslogMsgSDParamValue.1."snmp"."v".1="1.3.6.1.2.1.1.3.0" syslogMsgSDParamValue.1."snmp"."v".2="1.3.6.1.6.3.1.1.4.1.0" syslogMsgSDParamValue.1."snmp"."v".3="1.3.6.1.2.1.2.2.1.1.3" ... syslogMsgSDParamValue.1."snmp"."l".1="sysUpTime.0" syslogMsgSDParamValue.1."snmp"."l".2="snmpTrapOID.0" ... How can you tell the first occurrence of "l" is after "v".1 or "v".2? I.e., there may be possible that it is not 1:1 mapping from SDE to Table entries. Does that make sense? washam From j.schoenwaelder@jacobs-university.de Wed Feb 18 02:30:57 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 8EE983A6AA3 for ; Wed, 18 Feb 2009 02:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.135, 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 YneRyqtQABcn for ; Wed, 18 Feb 2009 02:30:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5EEDA3A6358 for ; Wed, 18 Feb 2009 02:30:56 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3688CC0110; Wed, 18 Feb 2009 11:31:08 +0100 (CET) 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 tKezCBMwHWTu; Wed, 18 Feb 2009 11:30:59 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC465C0111; Wed, 18 Feb 2009 11:30:59 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 8A68E9A5150; Wed, 18 Feb 2009 11:30:58 +0100 (CET) Date: Wed, 18 Feb 2009 11:30:58 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , opsawg@ietf.org References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> 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] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 10:30:57 -0000 On Wed, Feb 18, 2009 at 05:09:11PM +0800, WashamFan wrote: > Below is syslog messages from page10, syslog-snmp-00: > > <29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47 > [snmp ctxEngine="800002b804616263" ctxName="ctx1" > v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" > v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" > v="1.3.6.1.2.1.2.2.1.1.3" d="3" > v="1.3.6.1.2.1.2.2.1.7.3" d="1" > v="1.3.6.1.2.1.2.2.1.8.3" d="1"] > > I assume the corresponding entries in syslogMsgSDTable: > > syslogMsgIndex.1 = 1 > ... > syslogMsgSDParamValue.1."snmp"."v".1="1.3.6.1.2.1.1.3.0" > syslogMsgSDParamValue.1."snmp"."v".2="1.3.6.1.6.3.1.1.4.1.0" > syslogMsgSDParamValue.1."snmp"."v".3="1.3.6.1.2.1.2.2.1.1.3" > ... > syslogMsgSDParamValue.1."snmp"."l".1="sysUpTime.0" > syslogMsgSDParamValue.1."snmp"."l".2="snmpTrapOID.0" > ... > > How can you tell the first occurrence of "l" is after "v".1 or "v".2? > I.e., there may be possible that it is not 1:1 mapping from SDE to > Table entries. Does that make sense? OK, I now get your point. So if I understand correctly, a shorter example would be the following structured data element: [a c="c" b="b"] This maps to the following SNMP table entries (assuming syslogMsgIndex.1 = 1): syslogMsgSDParamValue.1."a"."b".1="b" syslogMsgSDParamValue.1."a"."c".1="c" The information that param c was before param b is lost. The question is whether this is relevant information to preserve. Perhaps it is. By changing the indexing structure, we can easily address this: syslogMsgSDParamValue.1."a".1."c"="c" syslogMsgSDParamValue.1."a".2."b"="b" The index before the param name would now be the position of the param within the structured data element. I think this change makes sense. Does everybody agree? /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 Feb 18 04:09: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 572C03A677E for ; Wed, 18 Feb 2009 04:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 r6SvzV725JMy for ; Wed, 18 Feb 2009 04:09:37 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 3F2B43A69F2 for ; Wed, 18 Feb 2009 04:09:37 -0800 (PST) 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 <0KF9004QFGG95C00@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 18 Feb 2009 20:09:47 +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 <0KF900LYPGG7LQ00@hstml02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 18 Feb 2009 20:09:45 +0800 (CST) Received: from [220.249.46.106] by hstml02-in.huaweisymantec.com (mshttpd) ; Wed, 18 Feb 2009 20:09:43 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Wed, 18 Feb 2009 20:09:43 +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: <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 18 Feb 2009 12:09:38 -0000 Hi, > On Wed, Feb 18, 2009 at 05:09:11PM +0800, WashamFan wrote: > > > Below is syslog messages from page10, syslog-snmp-00: > > > > <29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47 > > [snmp ctxEngine="800002b804616263" ctxName="ctx1" > > v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" > > v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" > > v="1.3.6.1.2.1.2.2.1.1.3" d="3" > > v="1.3.6.1.2.1.2.2.1.7.3" d="1" > > v="1.3.6.1.2.1.2.2.1.8.3" d="1"] > > > > I assume the corresponding entries in syslogMsgSDTable: > > > > syslogMsgIndex.1 = 1 > > ... > > syslogMsgSDParamValue.1."snmp"."v".1="1.3.6.1.2.1.1.3.0" > > syslogMsgSDParamValue.1."snmp"."v".2="1.3.6.1.6.3.1.1.4.1.0" > > syslogMsgSDParamValue.1."snmp"."v".3="1.3.6.1.2.1.2.2.1.1.3" > > ... > > syslogMsgSDParamValue.1."snmp"."l".1="sysUpTime.0" > > syslogMsgSDParamValue.1."snmp"."l".2="snmpTrapOID.0" > > ... > > > > How can you tell the first occurrence of "l" is after "v".1 or "v".2? > > I.e., there may be possible that it is not 1:1 mapping from SDE to > > Table entries. Does that make sense? > > OK, I now get your point. So if I understand correctly, a shorter > example would be the following structured data element: > > [a c="c" b="b"] > > This maps to the following SNMP table entries (assuming > syslogMsgIndex.1 = 1): > > syslogMsgSDParamValue.1."a"."b".1="b" > syslogMsgSDParamValue.1."a"."c".1="c" > > The information that param c was before param b is lost. The question > is whether this is relevant information to preserve. Perhaps it is. By > changing the indexing structure, we can easily address this: > > syslogMsgSDParamValue.1."a".1."c"="c" > syslogMsgSDParamValue.1."a".2."b"="b" > > The index before the param name would now be the position of the param > within the structured data element. I think this change makes sense. > > Does everybody agree? Yes, I agree. That is what I was concerned. washam > /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 j.schoenwaelder@jacobs-university.de Wed Feb 18 05:00: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 711293A6A33 for ; Wed, 18 Feb 2009 05:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.126, 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 T7msJbAOuEEv for ; Wed, 18 Feb 2009 05:00:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 43DC63A6C76 for ; Wed, 18 Feb 2009 05:00:36 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43CE4C012D; Wed, 18 Feb 2009 14:00:44 +0100 (CET) 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 n8zpLP+GpYNb; Wed, 18 Feb 2009 14:00:38 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 215AFC011B; Wed, 18 Feb 2009 14:00:38 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id D9C099A56CD; Wed, 18 Feb 2009 14:00:36 +0100 (CET) Date: Wed, 18 Feb 2009 14:00:36 +0100 From: Juergen Schoenwaelder To: WashamFan , opsawg@ietf.org Message-ID: <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , opsawg@ietf.org References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:00:37 -0000 On Wed, Feb 18, 2009 at 11:30:58AM +0100, Juergen Schoenwaelder wrote: > OK, I now get your point. So if I understand correctly, a shorter > example would be the following structured data element: > > [a c="c" b="b"] > > This maps to the following SNMP table entries (assuming syslogMsgIndex.1 = 1): > > syslogMsgSDParamValue.1."a"."b".1="b" > syslogMsgSDParamValue.1."a"."c".1="c" > > The information that param c was before param b is lost. The question > is whether this is relevant information to preserve. Perhaps it is. By > changing the indexing structure, we can easily address this: > > syslogMsgSDParamValue.1."a".1."c"="c" > syslogMsgSDParamValue.1."a".2."b"="b" > > The index before the param name would now be the position of the param > within the structured data element. I think this change makes sense. Thinking further; we have the same issue with the order of structured data elements. Consider this: [b b="b"][a c="c" a="a"] We would now get: syslogMsgSDParamValue.1."a".1."c"="c" syslogMsgSDParamValue.1."a".2."a"="a" syslogMsgSDParamValue.1."b".1."b"="b" So perhaps the position needs to be the second index and increment across structured data element boundaries: syslogMsgSDParamValue.1.1."b"."b"="b" syslogMsgSDParamValue.1.2."a"."c"="c" syslogMsgSDParamValue.1.3."a"."a"="a" This way, it should be possible to reconstruct all structured data elements in the correct order. /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 Feb 18 17:52:50 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 C339D3A696C for ; Wed, 18 Feb 2009 17:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.670, 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 6PIy3E5yuxNr for ; Wed, 18 Feb 2009 17:52:50 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id D773F3A67CF for ; Wed, 18 Feb 2009 17:52:49 -0800 (PST) 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 <0KFA007LGIKAJ550@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 19 Feb 2009 09:53:00 +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 <0KFA00B4KIK8UM20@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 19 Feb 2009 09:52:58 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 19 Feb 2009 09:52:56 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 19 Feb 2009 09:52:56 +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: <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 19 Feb 2009 01:52:50 -0000 Hi, > Thinking further; we have the same issue with the order of structured > data elements. Consider this: > > [b b="b"][a c="c" a="a"] > > We would now get: > > syslogMsgSDParamValue.1."a".1."c"="c" > syslogMsgSDParamValue.1."a".2."a"="a" > syslogMsgSDParamValue.1."b".1."b"="b" > > So perhaps the position needs to be the second index and increment > across structured data element boundaries: > > syslogMsgSDParamValue.1.1."b"."b"="b" > syslogMsgSDParamValue.1.2."a"."c"="c" > syslogMsgSDParamValue.1.3."a"."a"="a" > > This way, it should be possible to reconstruct all structured data > elements in the correct order. Yes. When we parse SDE, we may take into account where params position, but SDEs as a whole seems be independent with each other, I am not sure. But now it is a 1:1 mapping from syslog SDEs to syslogMsgSDTable entries, I think;) washam > /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 Washam.Fan@huaweisymantec.com Thu Feb 19 03:16:55 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 3F01328C194 for ; Thu, 19 Feb 2009 03:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 3yKxtCgZR6mR for ; Thu, 19 Feb 2009 03:16:54 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 541AF28C214 for ; Thu, 19 Feb 2009 03:16:54 -0800 (PST) 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 <0KFB007NW8OFA810@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 19 Feb 2009 19:17:04 +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 <0KFB002TO8ODKE00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 19 Feb 2009 19:17:02 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 19 Feb 2009 19:17:01 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 19 Feb 2009 19:17:01 +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 Cc: opsawg@ietf.org Subject: [OPSAWG] syslogMsgNotification, syslog-msg-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: Thu, 19 Feb 2009 11:16:55 -0000 Hi, para 2, description of syslogMsgNotification, page13 : "Implementations may add syslogMsgSDParamValue objects as long as the resulting notification fits into the size constraints imposed by the implementation environment and the notification message size constraints imposed by maxMessageSize [RFC3412] and SNMP transport mappings." so syslogMsgSDParamValue could be polled by snmp users? Are users expected to traverse all entries in syslogMsgSDTable? I don't think users can be sure they've got all SDEs in a syslog message without traversing all entries in syslogMsgSDTable. washam From j.schoenwaelder@jacobs-university.de Thu Feb 19 03:58: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 0D6DE3A69FD for ; Thu, 19 Feb 2009 03:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, 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 8ktFuRJkkZF9 for ; Thu, 19 Feb 2009 03:58:52 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 171E63A6823 for ; Thu, 19 Feb 2009 03:58:52 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1ABD8C0182; Thu, 19 Feb 2009 12:59:05 +0100 (CET) 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 rAmf0io-Bxqj; Thu, 19 Feb 2009 12:58:59 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22F44C0168; Thu, 19 Feb 2009 12:58:59 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 058999A70C9; Thu, 19 Feb 2009 12:58:57 +0100 (CET) Date: Thu, 19 Feb 2009 12:58:57 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090219115857.GC12569@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , opsawg@ietf.org References: 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] syslogMsgNotification, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 11:58:53 -0000 On Thu, Feb 19, 2009 at 07:17:01PM +0800, WashamFan wrote: > Hi, > > para 2, description of syslogMsgNotification, page13 : > > "Implementations may add syslogMsgSDParamValue objects as long > as the resulting notification fits into the size constraints > imposed by the implementation environment and the notification > message size constraints imposed by maxMessageSize [RFC3412] > and SNMP transport mappings." > > so syslogMsgSDParamValue could be polled by snmp users? > Are users expected to traverse all entries in syslogMsgSDTable? > I don't think users can be sure they've got all SDEs in a syslog > message without traversing all entries in syslogMsgSDTable. With the new indexing scheme, you can easily skip over params you have already received in the notification. If that last notification varbind is of the form syslogMsgSDParamValue.X.N."last"."thing", you can do a getnext/getbulk on syslogMsgSDParamValue.X.N. and should get additional params (e.g. syslogMsgSDParamValue.X.N+1."some"."thing") or you get something that does not belong to the syslog message in question. /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 Thu Feb 19 12:31: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 6814A3A6C00 for ; Thu, 19 Feb 2009 12:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.164, 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 ZlmXOJucvQhi for ; Thu, 19 Feb 2009 12:30:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 94F4B3A69A3 for ; Thu, 19 Feb 2009 12:30:59 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C0D3176C310 for ; Thu, 19 Feb 2009 21:24:28 +0100 (CET) Date: Thu, 19 Feb 2009 21:24:28 +0100 (CET) Message-Id: <20090219.212428.94707851.mbj@tail-f.com> To: opsawg@ietf.org From: Martin Bjorklund 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 Subject: [OPSAWG] comments ion syslog-msg-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: Thu, 19 Feb 2009 20:31:00 -0000 Hi, I have a few minor comments on this document. In the syslogMsgTable, some of the objects have special values when the corresponding field has no value in the original syslog message. For example, syslogMsgTimeStamp uses a value of 20 zeros. I just wonder why this scheme is chosen instead of simply not making the instance available? Is this some BCP? This also means that these dummy values are sent in the syslogMsgNotification I guess? Should the object syslogMsgSDElementName be called syslogMsgSDElementID (or just syslogMsgSDID) to match the terminology in the syslog spec? In the DESCRIPTION of syslogMsgSDParamIndex: s/This objects indexes/This object indexes/ s/instance of a structured data element/ instance of a parameter/ s/occure/occurs/ In the DESCRIPTION of syslogMsgNotification: "The syslogMsgNotification is generated when a new syslog message is generated" ^^^^^^^^^^^^ Do you mean "is received"? In syslogMsgNotificationCompliance you say that the syslogMsg* objects have a MIN-ACCESS accessible-for-notify. I just wonder what the instance identifier part of these objects would be in the varbind list of syslogMsgNotification in this case? /martin From j.schoenwaelder@jacobs-university.de Thu Feb 19 23:51: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 76AE53A6A1D for ; Thu, 19 Feb 2009 23:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 uXIaiDrjbAWB for ; Thu, 19 Feb 2009 23:51:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2C5A63A6957 for ; Thu, 19 Feb 2009 23:51:19 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C85C4C0108; Fri, 20 Feb 2009 08:51:32 +0100 (CET) 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 UMEBzwDq6mYX; Fri, 20 Feb 2009 08:51:26 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3B67C006A; Fri, 20 Feb 2009 08:51:26 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id B403E9A7D7B; Fri, 20 Feb 2009 08:51:25 +0100 (CET) Date: Fri, 20 Feb 2009 08:51:25 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090220075125.GA13863@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , opsawg@ietf.org References: <20090219.212428.94707851.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090219.212428.94707851.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments ion syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 07:51:20 -0000 On Thu, Feb 19, 2009 at 09:24:28PM +0100, Martin Bjorklund wrote: > In the syslogMsgTable, some of the objects have special values when > the corresponding field has no value in the original syslog message. > For example, syslogMsgTimeStamp uses a value of 20 zeros. I just > wonder why this scheme is chosen instead of simply not making the > instance available? Is this some BCP? This also means that these > dummy values are sent in the syslogMsgNotification I guess? There are I think two reasons: a) Some applications apparently do not deal well with holes in tables. b) RFC 3416 says for notifications: If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, to the variable-bindings field. It is somewhat unclear how to interpret this text if notification objects do not exist. (Note that variables protected by access control cause the whole notification to be dropped.) We bypass this issue by making sure the objects always exist. Since syslogMsgTimeStamp now uses DateAndTimeMicroSeconds, one could perhaps choose a zero-length string in order to save some 20 bytes in the cases where the timestamp is not known. Perhaps I should change the name of DateAndTimeMicroSeconds to SyslogTimeStamp and leave it to some other module to define a reusable DateAndTimeMicroSeconds TC. > Should the object syslogMsgSDElementName be called > syslogMsgSDElementID (or just syslogMsgSDID) to match the > terminology in the syslog spec? Yes, but then I would choose syslogMsgSDID as this is closest to the SYSLOG protocol specificiation. > In the DESCRIPTION of syslogMsgSDParamIndex: > s/This objects indexes/This object indexes/ > s/instance of a structured data element/ > instance of a parameter/ > s/occure/occurs/ This text has already been rewritten since we changed the semantics of this object to reflect the position of the param. It now reads: syslogMsgSDParamIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object indexes the structured data element parameters contained in a SYSLOG message. The first structured data element parameter has the index value 1 and subsequent parameters are indexed by incrementing the index of the previous parameter. The index increases across structured data element boundaries so that the value reflects the position of a structured data element parameter in a SYSLOG message." REFERENCE "RFCYYYY: The syslog Protocol (section 6.3.3)" ::= { syslogMsgSDEntry 1 } > In the DESCRIPTION of syslogMsgNotification: > "The syslogMsgNotification is generated when a new syslog > message is generated" > ^^^^^^^^^^^^ > Do you mean "is received"? Yes, fixed. > In syslogMsgNotificationCompliance you say that the syslogMsg* objects > have a MIN-ACCESS accessible-for-notify. I just wonder what the > instance identifier part of these objects would be in the varbind list > of syslogMsgNotification in this case? The MIN-ACCESS does not change how the instance identifier is formed. You do exactly the same as if the objects were accessible except that you can't access them. /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 Fri Feb 20 00:17:04 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 93F413A6A1D for ; Fri, 20 Feb 2009 00:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.149, 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 KBKu6K4YyGLO for ; Fri, 20 Feb 2009 00:17:04 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CDD6B3A684F for ; Fri, 20 Feb 2009 00:17:03 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BD98C76C322; Fri, 20 Feb 2009 09:17:16 +0100 (CET) Date: Fri, 20 Feb 2009 09:17:12 +0100 (CET) Message-Id: <20090220.091712.163571569.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090220075125.GA13863@elstar.iuhb02.iu-bremen.de> References: <20090219.212428.94707851.mbj@tail-f.com> <20090220075125.GA13863@elstar.iuhb02.iu-bremen.de> 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] comments ion syslog-msg-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, 20 Feb 2009 08:17:04 -0000 Juergen Schoenwaelder wrote: > On Thu, Feb 19, 2009 at 09:24:28PM +0100, Martin Bjorklund wrote: > > In syslogMsgNotificationCompliance you say that the syslogMsg* objects > > have a MIN-ACCESS accessible-for-notify. I just wonder what the > > instance identifier part of these objects would be in the varbind list > > of syslogMsgNotification in this case? > > The MIN-ACCESS does not change how the instance identifier is > formed. You do exactly the same as if the objects were accessible > except that you can't access them. So it would be ok to always use syslogMsgIndex 1 in all notifications? Or any random Unsigned32 value != 0? /martin From j.schoenwaelder@jacobs-university.de Fri Feb 20 01:12:11 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 E44F13A6899 for ; Fri, 20 Feb 2009 01:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 tcRXF7k4kUAQ for ; Fri, 20 Feb 2009 01:12:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D60773A67C1 for ; Fri, 20 Feb 2009 01:12:10 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF580C018F; Fri, 20 Feb 2009 10:12:24 +0100 (CET) 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 ethmjrY6zlb8; Fri, 20 Feb 2009 10:12:19 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0279FC0164; Fri, 20 Feb 2009 10:12:18 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id CB9A49A7FC9; Fri, 20 Feb 2009 10:12:17 +0100 (CET) Date: Fri, 20 Feb 2009 10:12:17 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090220091217.GB12614@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , opsawg@ietf.org References: <20090219.212428.94707851.mbj@tail-f.com> <20090220075125.GA13863@elstar.iuhb02.iu-bremen.de> <20090220.091712.163571569.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220.091712.163571569.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments ion syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 09:12:12 -0000 On Fri, Feb 20, 2009 at 09:17:12AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Feb 19, 2009 at 09:24:28PM +0100, Martin Bjorklund wrote: > > > In syslogMsgNotificationCompliance you say that the syslogMsg* objects > > > have a MIN-ACCESS accessible-for-notify. I just wonder what the > > > instance identifier part of these objects would be in the varbind list > > > of syslogMsgNotification in this case? > > > > The MIN-ACCESS does not change how the instance identifier is > > formed. You do exactly the same as if the objects were accessible > > except that you can't access them. > > So it would be ok to always use syslogMsgIndex 1 in all notifications? > Or any random Unsigned32 value != 0? I do not see this mentioned in the description of syslogMsgIndex. Ah, because the description does not state the value starts with 1? If your implementation can't affort a 32-bit counter, you might claim that the MIB module suffers from a discontinuity due to a restart of the submodule after ever notification generated... /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 Sun Feb 22 23:15:14 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 D5FC73A6806 for ; Sun, 22 Feb 2009 23:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_50=0.001] 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 Pc9Gajqz5AzU for ; Sun, 22 Feb 2009 23:15:14 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id CB5983A67AA for ; Sun, 22 Feb 2009 23:15:13 -0800 (PST) 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 <0KFI00IH0C5Q4310@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Mon, 23 Feb 2009 15:15:28 +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 <0KFI009I7C5OV900@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Mon, 23 Feb 2009 15:15:26 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 23 Feb 2009 15:15:24 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Mon, 23 Feb 2009 15:15:24 +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: <20090219115857.GC12569@elstar.iuhb02.iu-bremen.de> References: <20090219115857.GC12569@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgNotification, syslog-msg-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, 23 Feb 2009 07:15:14 -0000 > On Thu, Feb 19, 2009 at 07:17:01PM +0800, WashamFan wrote: > > Hi, > > > > para 2, description of syslogMsgNotification, page13 : > > > > "Implementations may add syslogMsgSDParamValue objects as long > > as the resulting notification fits into the size constraints > > imposed by the implementation environment and the notification > > message size constraints imposed by maxMessageSize [RFC3412] > > and SNMP transport mappings." > > > > so syslogMsgSDParamValue could be polled by snmp users? > > Are users expected to traverse all entries in syslogMsgSDTable? > > I don't think users can be sure they've got all SDEs in a syslog > > message without traversing all entries in syslogMsgSDTable. > > With the new indexing scheme, you can easily skip over params you have > already received in the notification. If that last notification > varbind is of the form syslogMsgSDParamValue.X.N."last"."thing", you > can do a getnext/getbulk on syslogMsgSDParamValue.X.N. and should get > additional params (e.g. syslogMsgSDParamValue.X.N+1."some"."thing") or > you get something that does not belong to the syslog message in > question. So there are some assumptions: 1) At least one syslogMsgSDParamValue exists in notification, what if there is no syslogMsgSDParamValue but sdparams bit is set? 2) syslogMsgSDTable entries belonging to the same syslogMsgIndex MUST be stored consecutively. In your example, you getnext until you get something that does not belong to the syslog message in question. What does 'somthing' refer to? next entry belonging to another syslogMsgIndex or access control denied error? In new indexing schema, what should be put in syslogMsgSDEntry INDEX clause? It remains the same or only helds 'syslogMsgIndex' and 'syslogMsgSDParamIndex'? washam > /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 j.schoenwaelder@jacobs-university.de Sun Feb 22 23:25:25 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 1C7BB3A681D for ; Sun, 22 Feb 2009 23:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 m2UAWJVxxpy1 for ; Sun, 22 Feb 2009 23:25:23 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 37E0F3A67A1 for ; Sun, 22 Feb 2009 23:25:16 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9267C00EA; Mon, 23 Feb 2009 08:25:33 +0100 (CET) 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 yGFBXtHqVJnr; Mon, 23 Feb 2009 08:25:27 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FB52C00E8; Mon, 23 Feb 2009 08:25:27 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 62AFB9AB855; Mon, 23 Feb 2009 08:25:26 +0100 (CET) Date: Mon, 23 Feb 2009 08:25:26 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090223072526.GA23980@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , opsawg@ietf.org References: <20090219115857.GC12569@elstar.iuhb02.iu-bremen.de> 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] syslogMsgNotification, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 07:25:25 -0000 On Mon, Feb 23, 2009 at 03:15:24PM +0800, WashamFan wrote: > So there are some assumptions: > 1) At least one syslogMsgSDParamValue exists in notification, what if there > is no syslogMsgSDParamValue but sdparams bit is set? You can still construct a GetNext with syslogMsgSDParamIndex=0. > 2) syslogMsgSDTable entries belonging to the same syslogMsgIndex MUST > be stored consecutively. They can be stored in whatever way you like to store them. The instance identifier however ensure that the lexicographic ordering is in increasing order of syslogMsgSDParamIndex. > In your example, you getnext until you get something that does not belong > to the syslog message in question. What does 'somthing' refer to? next entry > belonging to another syslogMsgIndex or access control denied error? GetNext never returs an access control denied error. You iterate until you get something that does not belong to the syslog message in question - it might be a syslogMsgSDParamName of a different syslog message or something completely different. > In new indexing schema, what should be put in syslogMsgSDEntry INDEX > clause? It remains the same or only helds 'syslogMsgIndex' and > 'syslogMsgSDParamIndex'? INDEX { syslogMsgIndex, syslogMsgSDParamIndex, syslogMsgSDID, syslogMsgSDParamName } You still need to know the SDID and the name of the param in order to make sense of a value. I just changed the order of the INDEX components. /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 Feb 23 12:18:55 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 D14CC3A68BA for ; Mon, 23 Feb 2009 12:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.141, 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 A6qT07KCFD7f for ; Mon, 23 Feb 2009 12:18:55 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 056513A67E2 for ; Mon, 23 Feb 2009 12:18:54 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7DA9276C225; Mon, 23 Feb 2009 21:19:11 +0100 (CET) Date: Mon, 23 Feb 2009 21:19:11 +0100 (CET) Message-Id: <20090223.211911.104688150.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090220091217.GB12614@elstar.iuhb02.iu-bremen.de> References: <20090220075125.GA13863@elstar.iuhb02.iu-bremen.de> <20090220.091712.163571569.mbj@tail-f.com> <20090220091217.GB12614@elstar.iuhb02.iu-bremen.de> 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] comments ion syslog-msg-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, 23 Feb 2009 20:18:55 -0000 Juergen Schoenwaelder wrote: > On Fri, Feb 20, 2009 at 09:17:12AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Feb 19, 2009 at 09:24:28PM +0100, Martin Bjorklund wrote: > > > > In syslogMsgNotificationCompliance you say that the syslogMsg* objects > > > > have a MIN-ACCESS accessible-for-notify. I just wonder what the > > > > instance identifier part of these objects would be in the varbind list > > > > of syslogMsgNotification in this case? > > > > > > The MIN-ACCESS does not change how the instance identifier is > > > formed. You do exactly the same as if the objects were accessible > > > except that you can't access them. > > > > So it would be ok to always use syslogMsgIndex 1 in all notifications? > > Or any random Unsigned32 value != 0? > > I do not see this mentioned in the description of syslogMsgIndex. Ah, > because the description does not state the value starts with 1? The object is defined to "identify entries in the syslogMsgTable". But in this case there are no such entries. Hmm, I guess that conceptually there *are* entries, but they are not accessible other than through the notifciations. > If your implementation can't affort a 32-bit counter, you might > claim that the MIB module suffers from a discontinuity due to a > restart of the submodule after ever notification generated... After your clarification it is clear to me how it should be implemented if the table is accessible-for-notify. /martin From mbj@tail-f.com Mon Feb 23 12:53:56 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 A31263A68A6 for ; Mon, 23 Feb 2009 12:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.133, 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 1dq9Bu0A0ipN for ; Mon, 23 Feb 2009 12:53:55 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BF2A53A6897 for ; Mon, 23 Feb 2009 12:53:52 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 037B576C225 for ; Mon, 23 Feb 2009 21:54:10 +0100 (CET) Date: Mon, 23 Feb 2009 21:54:09 +0100 (CET) Message-Id: <20090223.215409.145407580.mbj@tail-f.com> To: opsawg@ietf.org From: Martin Bjorklund 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 Subject: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00 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, 23 Feb 2009 20:53:56 -0000 Hi, Some comments on this draft. The picture on page 6 could benefit from changing some of the lines into arrows - I think the picture tries to illustrate the flow of notifications (from right to left). The grammar in section 3.2 (and also section 5) makes the ctxEngineId and ctxEngineName SD-ELEMENT parameters optional. But the text in 3.2 says: The first two PARAM-NAME elements are "ctxEngine" and "ctxName". They must be present in an SNMPv3 notification and therefore they must be present in a SYSLOG message generated by an snmp-to-syslog translator. So the question is if they are optional, or maybe MUST be present? Further, the text in 3.2 says "the contextName is encoded as a hexadecimal string." but the grammar specifies it as a UTF8 string. The grammar in 3.2 also includes an optional VARLABEL, which isn't further discussed in the text. I assume the intention is that if this label is known to the snmp-to-syslog translator, then it may be included, to make the resulting syslog message easier to read. But this makes me wonder a bit of the environments in which this kind of translator will be used, and the objectives of this draft. The mapping as it is defined isn't really useful unless an application on the receiving side (syslog server) has SNMP / MIB knowledge. Specifically, a human user cannot easily read those messages and extract useful information. I suspect human readability is not the goal of this mapping. I think this should be discussed in the intro of the draft. If the mapping is supposed to cover both machine and human readability, then the VARLABEL seems a bit arbitrary (since even DisplayStrings are encoded in hex - *if* the translator has MIB knowledge it would seem fine to encode DisplayStrings and Utf8Strings as utf8) /martin From j.schoenwaelder@jacobs-university.de Mon Feb 23 13:22:06 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 5FD353A6A72 for ; Mon, 23 Feb 2009 13:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Q8DTlFBH-BIP for ; Mon, 23 Feb 2009 13:22:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3F6A83A6833 for ; Mon, 23 Feb 2009 13:22:05 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92350C012E; Mon, 23 Feb 2009 22:22:22 +0100 (CET) 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 Ld1Z2S8Yo98G; Mon, 23 Feb 2009 22:22:17 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BA8BC0081; Mon, 23 Feb 2009 22:22:17 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id F01389AC6D2; Mon, 23 Feb 2009 22:22:15 +0100 (CET) Date: Mon, 23 Feb 2009 22:22:15 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090223212215.GA25246@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , opsawg@ietf.org References: <20090220075125.GA13863@elstar.iuhb02.iu-bremen.de> <20090220.091712.163571569.mbj@tail-f.com> <20090220091217.GB12614@elstar.iuhb02.iu-bremen.de> <20090223.211911.104688150.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090223.211911.104688150.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments ion syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:22:06 -0000 On Mon, Feb 23, 2009 at 09:19:11PM +0100, Martin Bjorklund wrote: > The object is defined to "identify entries in the syslogMsgTable". > But in this case there are no such entries. Hmm, I guess that > conceptually there *are* entries, but they are not accessible other > than through the notifciations. Your last sentence is a good summary of my interpretation of what accessible-for-notify means. There is not a great deal of text about accessible-for-notify in RFC 2578. But I think this interpretation makes sense and is consistent with the rest of the framework (e.g. how access control is checked for notification objects). /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 Mon Feb 23 13:38:35 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 3CDEC3A69A0 for ; Mon, 23 Feb 2009 13:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 xf46L93xLrRp for ; Mon, 23 Feb 2009 13:38:34 -0800 (PST) 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 043BF28C15A for ; Mon, 23 Feb 2009 13:37:40 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA04.westchester.pa.mail.comcast.net with comcast id KSyl1b00C0SCNGk54Ze0EC; Mon, 23 Feb 2009 21:38:00 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id KZdy1b00t0UQ6dC3VZdyQC; Mon, 23 Feb 2009 21:38:00 +0000 From: "David Harrington" To: , "'Martin Bjorklund'" References: <20090220075125.GA13863@elstar.iuhb02.iu-bremen.de><20090220.091712.163571569.mbj@tail-f.com><20090220091217.GB12614@elstar.iuhb02.iu-bremen.de><20090223.211911.104688150.mbj@tail-f.com> <20090223212215.GA25246@elstar.iuhb02.iu-bremen.de> Date: Mon, 23 Feb 2009 16:37:57 -0500 Message-ID: <085d01c995fe$ff2de740$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090223212215.GA25246@elstar.iuhb02.iu-bremen.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmV/NjlEiBv2HnoS4Gh6PgWBU+abwAAbjAA Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments ion syslog-msg-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, 23 Feb 2009 21:38:35 -0000 Hi, As I recall from the SNMPv3 WG, accessible-for-notify was added to support devices like printers that might have events it wants to report, but the device does not support having MIBs instantiated (i.e., you cannot GET or SET the information). IIRC, the idea was for things like out-of-ink notifications that could be generated dynamically as needed. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Monday, February 23, 2009 4:22 PM > To: Martin Bjorklund > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] comments ion syslog-msg-mib-01 > > On Mon, Feb 23, 2009 at 09:19:11PM +0100, Martin Bjorklund wrote: > > > The object is defined to "identify entries in the syslogMsgTable". > > But in this case there are no such entries. Hmm, I guess that > > conceptually there *are* entries, but they are not accessible other > > than through the notifciations. > > Your last sentence is a good summary of my interpretation of what > accessible-for-notify means. There is not a great deal of text about > accessible-for-notify in RFC 2578. But I think this interpretation > makes sense and is consistent with the rest of the framework (e.g. > how access control is checked for notification objects). > > /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 j.schoenwaelder@jacobs-university.de Tue Feb 24 00:00:12 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 3E6083A67D1 for ; Tue, 24 Feb 2009 00:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 jt9W5pfUXG9T for ; Tue, 24 Feb 2009 00:00:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 175313A6991 for ; Tue, 24 Feb 2009 00:00:10 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71549C012F; Tue, 24 Feb 2009 09:00:28 +0100 (CET) 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 dZV05E60p0dH; Tue, 24 Feb 2009 09:00:22 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 012CEC0081; Tue, 24 Feb 2009 09:00:21 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id C1BEF9ACBCC; Tue, 24 Feb 2009 09:00:20 +0100 (CET) Date: Tue, 24 Feb 2009 09:00:20 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090224080020.GA25631@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , opsawg@ietf.org References: <20090223.215409.145407580.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090223.215409.145407580.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 08:00:12 -0000 On Mon, Feb 23, 2009 at 09:54:09PM +0100, Martin Bjorklund wrote: > Some comments on this draft. > > The picture on page 6 could benefit from changing some of the lines > into arrows - I think the picture tries to illustrate the flow of > notifications (from right to left). I have added arrow heads. > The grammar in section 3.2 (and also section 5) makes the ctxEngineId > and ctxEngineName SD-ELEMENT parameters optional. But the text in 3.2 > says: > > The first two PARAM-NAME elements are "ctxEngine" and "ctxName". > They must be present in an SNMPv3 notification and therefore they > must be present in a SYSLOG message generated by an snmp-to-syslog > translator. > > So the question is if they are optional, or maybe MUST be present? The idea is that "ctxEngine" and "ctxName" are a MUST for SNMPv3 and they are optional for other versions of SNMP. This is hinted at on page 4: In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID and the contextName parameters are not present in notification messages. I will clarify the sentence as follows: The first two PARAM-NAME elements are "ctxEngine" and "ctxName". They must be present in an SNMPv3 notification and therefore they must be present in a SYSLOG message generated by an snmp-to-syslog translator from an SNMPv3 notification. > Further, the text in 3.2 says "the contextName is encoded as a > hexadecimal string." but the grammar specifies it as a UTF8 string. Since SnmpAdminString is used in several MIB modules where context names appear, I assume UTF8 string is the right choice. New text: The contexdEngineID is encoded as as hexadecimal string while the contextName is encoded as a UTF8 string. > The grammar in 3.2 also includes an optional VARLABEL, which isn't > further discussed in the text. I assume the intention is that if this > label is known to the snmp-to-syslog translator, then it may be > included, to make the resulting syslog message easier to read. But > this makes me wonder a bit of the environments in which this kind of > translator will be used, and the objectives of this draft. The > mapping as it is defined isn't really useful unless an application on > the receiving side (syslog server) has SNMP / MIB knowledge. > Specifically, a human user cannot easily read those messages and > extract useful information. I suspect human readability is not the > goal of this mapping. I think this should be discussed in the intro > of the draft. If the mapping is supposed to cover both machine and > human readability, then the VARLABEL seems a bit arbitrary (since even > DisplayStrings are encoded in hex - *if* the translator has MIB > knowledge it would seem fine to encode DisplayStrings and Utf8Strings > as utf8) The question boils down to whether we can assume MIB knowledge of the translator or not. I believe in the general case we can not assume full MIB knowledge since a certain percentage of notifications tends to be device/vendor specific and it is unrealistic to assume that an implementation will know all MIB modules. If this is true, then we have to ship OIDs and hex data for certain notifications to the receiver. So one extreme approach is to simply keep the translator dumb and put the burdon on the receiver's side (and it should be fairly easy to write a filter, e.g. an extended version of smixlate, that takes SYSLOG messages and translates OIDs and values into something more human friendly). This is where this document originally started from. However, for some device vendors who like to put the translator into their devices, the situation is different because they can ensure that they have full MIB knowledge and thus translations can happen on the device. This is why we added VARLABEL and the question that you bring up now is whether we should also support alternate value representations via an 'a' parameter, which contains the value representation generated by applying DISPLAY-HINTs or replacing numbers with labels in enumerations and bits so that v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" v="1.3.6.1.2.1.2.2.1.1.3" d="3" v="1.3.6.1.2.1.2.2.1.7.3" d="1" v="1.3.6.1.2.1.2.2.1.8.3" d="1" becomes v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" a="linkUp" v="1.3.6.1.2.1.2.2.1.1.3" l="ifIndex.3" d="3" v="1.3.6.1.2.1.2.2.1.7.3" l="ifAdminStatus.3" d="1" a="up" v="1.3.6.1.2.1.2.2.1.8.3" l="ifOperStatus.3" d="1" a="up" The only downside is the obvious increase in length but on the other hand the operational value of the result might increase significantly. Comments? /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 Feb 24 02:19:14 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 D4EB63A6868 for ; Tue, 24 Feb 2009 02:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.124, 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 rjOakuRLmioo for ; Tue, 24 Feb 2009 02:19:13 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5E2CD3A6A9A for ; Tue, 24 Feb 2009 02:19:13 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 98E7A76C341; Tue, 24 Feb 2009 11:19:30 +0100 (CET) Date: Tue, 24 Feb 2009 11:19:28 +0100 (CET) Message-Id: <20090224.111928.256426913.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090224080020.GA25631@elstar.iuhb02.iu-bremen.de> References: <20090223.215409.145407580.mbj@tail-f.com> <20090224080020.GA25631@elstar.iuhb02.iu-bremen.de> 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] comments on draft-ietf-opsawg-syslog-snmp-00 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, 24 Feb 2009 10:19:14 -0000 Juergen Schoenwaelder wrote: > > The grammar in section 3.2 (and also section 5) makes the ctxEngineId > > and ctxEngineName SD-ELEMENT parameters optional. But the text in 3.2 > > says: > > > > The first two PARAM-NAME elements are "ctxEngine" and "ctxName". > > They must be present in an SNMPv3 notification and therefore they > > must be present in a SYSLOG message generated by an snmp-to-syslog > > translator. > > > > So the question is if they are optional, or maybe MUST be present? > > The idea is that "ctxEngine" and "ctxName" are a MUST for SNMPv3 and > they are optional for other versions of SNMP. This is hinted at on > page 4: > > In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID > and the contextName parameters are not present in notification > messages. But the next sentence after the one you quoted says: In general, we assume that notifications from an SNMP version preceding SNMPv3 are mapped into the notification format used by SNMPv3 according to the coexistance rules defined in RFC 3584 [RFC3584]. After translation, each notification will have a contextEngineID and contextName. Otherwise, what is the point of this sentence? > The question boils down to whether we can assume MIB knowledge of the > translator or not. I believe in the general case we can not assume > full MIB knowledge Agreed. > since a certain percentage of notifications tends > to be device/vendor specific and it is unrealistic to assume that an > implementation will know all MIB modules. If this is true, then we > have to ship OIDs and hex data for certain notifications to the > receiver. So one extreme approach is to simply keep the translator > dumb and put the burdon on the receiver's side (and it should be > fairly easy to write a filter, e.g. an extended version of smixlate, > that takes SYSLOG messages and translates OIDs and values into > something more human friendly). This is where this document originally > started from. Ok. I think a short note about this should go into the introduction. But stepping back, is it realistic to assume that an environment exists where you can have a syslog server with full MIB knowledge, but not have a SNMP trap sink? > However, for some device vendors who like to put the translator into > their devices, the situation is different because they can ensure that > they have full MIB knowledge and thus translations can happen on the > device. This is why we added VARLABEL and the question that you bring > up now is whether we should also support alternate value > representations via an 'a' parameter, which contains the value > representation generated by applying DISPLAY-HINTs or replacing > numbers with labels in enumerations and bits so that > > v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" > v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" > v="1.3.6.1.2.1.2.2.1.1.3" d="3" > v="1.3.6.1.2.1.2.2.1.7.3" d="1" > v="1.3.6.1.2.1.2.2.1.8.3" d="1" > > becomes > > v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" > v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" > a="linkUp" > v="1.3.6.1.2.1.2.2.1.1.3" l="ifIndex.3" d="3" > v="1.3.6.1.2.1.2.2.1.7.3" l="ifAdminStatus.3" d="1" a="up" > v="1.3.6.1.2.1.2.2.1.8.3" l="ifOperStatus.3" d="1" a="up" > > The only downside is the obvious increase in length but on the other > hand the operational value of the result might increase significantly. > > Comments? I think that something like this would be useful, and by making it optional, the translator can decide if the increased size is acceptable or not. The 'a' parameter seems useful, but in many cases it seems the information is redundant - if the receiver does not have MIB knowledge, the 'd' parameter is not very useful, but 'a' is. OTOH if the receiver has MIB knowledge, the 'd' value can be calculated from the 'a' value. As another example, if the type is DisplayString it seems like a waste of bytes to send the value as a ascii string *and* as a hexstring. /martin From j.schoenwaelder@jacobs-university.de Tue Feb 24 04:33:27 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 85A8428C1E5 for ; Tue, 24 Feb 2009 04:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 H4T8PvDggcZ1 for ; Tue, 24 Feb 2009 04:33:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 10E3928C18F for ; Tue, 24 Feb 2009 04:33:26 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9849C0157; Tue, 24 Feb 2009 13:33:44 +0100 (CET) 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 HX+49s0q2-zb; Tue, 24 Feb 2009 13:33:37 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D67AC0151; Tue, 24 Feb 2009 13:33:37 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 0124F9AD0E5; Tue, 24 Feb 2009 13:33:31 +0100 (CET) Date: Tue, 24 Feb 2009 13:33:31 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090224123331.GB26046@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , opsawg@ietf.org References: <20090223.215409.145407580.mbj@tail-f.com> <20090224080020.GA25631@elstar.iuhb02.iu-bremen.de> <20090224.111928.256426913.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224.111928.256426913.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 12:33:27 -0000 On Tue, Feb 24, 2009 at 11:19:28AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > The grammar in section 3.2 (and also section 5) makes the ctxEngineId > > > and ctxEngineName SD-ELEMENT parameters optional. But the text in 3.2 > > > says: > > > > > > The first two PARAM-NAME elements are "ctxEngine" and "ctxName". > > > They must be present in an SNMPv3 notification and therefore they > > > must be present in a SYSLOG message generated by an snmp-to-syslog > > > translator. > > > > > > So the question is if they are optional, or maybe MUST be present? > > > > The idea is that "ctxEngine" and "ctxName" are a MUST for SNMPv3 and > > they are optional for other versions of SNMP. This is hinted at on > > page 4: > > > > In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID > > and the contextName parameters are not present in notification > > messages. > > But the next sentence after the one you quoted says: > > In general, we assume that notifications from an SNMP version > preceding SNMPv3 are mapped into the notification format used by > SNMPv3 according to the coexistance rules defined in RFC 3584 > [RFC3584]. > > After translation, each notification will have a contextEngineID and > contextName. Otherwise, what is the point of this sentence? Its about the mapping of the notification payload format. In concrete terms: SNMPv1 traps are mapped using RFC 3584 to the new format. The text could probably be more specific. The fine detail here is that an automatic extraction of "ctxEngine" and "ctxName" out of SNMPv1/SNMPv2c messages is not possible unless the translator has access to a mapping table (which might be the case if the translator is integrated into the management software of a device but once the translator sits outside the device, this information is usually not available). > > since a certain percentage of notifications tends > > to be device/vendor specific and it is unrealistic to assume that an > > implementation will know all MIB modules. If this is true, then we > > have to ship OIDs and hex data for certain notifications to the > > receiver. So one extreme approach is to simply keep the translator > > dumb and put the burdon on the receiver's side (and it should be > > fairly easy to write a filter, e.g. an extended version of smixlate, > > that takes SYSLOG messages and translates OIDs and values into > > something more human friendly). This is where this document originally > > started from. > > Ok. I think a short note about this should go into the introduction. > > But stepping back, is it realistic to assume that an environment > exists where you can have a syslog server with full MIB knowledge, but > not have a SNMP trap sink? Mappings from SNMP to SYSLOG have been done in the past and I believe the reasons for having these mappings will persist. Architecturally, the SNMP to SYSLOG translator is an SNMP notification receiver (an SNMP trap sink). So I am not sure I understand your question. > > However, for some device vendors who like to put the translator into > > their devices, the situation is different because they can ensure that > > they have full MIB knowledge and thus translations can happen on the > > device. This is why we added VARLABEL and the question that you bring > > up now is whether we should also support alternate value > > representations via an 'a' parameter, which contains the value > > representation generated by applying DISPLAY-HINTs or replacing > > numbers with labels in enumerations and bits so that > > > > v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" > > v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" > > v="1.3.6.1.2.1.2.2.1.1.3" d="3" > > v="1.3.6.1.2.1.2.2.1.7.3" d="1" > > v="1.3.6.1.2.1.2.2.1.8.3" d="1" > > > > becomes > > > > v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" > > v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" > > a="linkUp" > > v="1.3.6.1.2.1.2.2.1.1.3" l="ifIndex.3" d="3" > > v="1.3.6.1.2.1.2.2.1.7.3" l="ifAdminStatus.3" d="1" a="up" > > v="1.3.6.1.2.1.2.2.1.8.3" l="ifOperStatus.3" d="1" a="up" > > > > The only downside is the obvious increase in length but on the other > > hand the operational value of the result might increase significantly. > > > > Comments? > > I think that something like this would be useful, and by making it > optional, the translator can decide if the increased size is > acceptable or not. > > The 'a' parameter seems useful, but in many cases it seems the > information is redundant - if the receiver does not have MIB > knowledge, the 'd' parameter is not very useful, but 'a' is. OTOH if > the receiver has MIB knowledge, the 'd' value can be calculated from > the 'a' value. As another example, if the type is DisplayString it > seems like a waste of bytes to send the value as a ascii string *and* > as a hexstring. So you are arguing now against having the 'a' format since it is redundant? I like to have a basic format I can rely on being there all the time. If there is additional rendering for human beings, fine. But I would hate to get something like: l="asdf.42" a="boogoo" where I have no chance to figure out what it means - is boogoo an enum or a string value? And what is asdf.42 anyway? So I like to have always the OID and a straight mapping of the value and its type information. /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 Feb 24 06:27: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 DDF6D3A6872 for ; Tue, 24 Feb 2009 06:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.106, 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 kU48pxixRqlM for ; Tue, 24 Feb 2009 06:27:00 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BA2D33A67A2 for ; Tue, 24 Feb 2009 06:26:59 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B80C76C341; Tue, 24 Feb 2009 15:27:16 +0100 (CET) Date: Tue, 24 Feb 2009 15:27:15 +0100 (CET) Message-Id: <20090224.152715.44247666.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090224123331.GB26046@elstar.iuhb02.iu-bremen.de> References: <20090224080020.GA25631@elstar.iuhb02.iu-bremen.de> <20090224.111928.256426913.mbj@tail-f.com> <20090224123331.GB26046@elstar.iuhb02.iu-bremen.de> 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] comments on draft-ietf-opsawg-syslog-snmp-00 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, 24 Feb 2009 14:27:00 -0000 Juergen Schoenwaelder wrote: > > But the next sentence after the one you quoted says: > > > > In general, we assume that notifications from an SNMP version > > preceding SNMPv3 are mapped into the notification format used by > > SNMPv3 according to the coexistance rules defined in RFC 3584 > > [RFC3584]. > > > > After translation, each notification will have a contextEngineID and > > contextName. Otherwise, what is the point of this sentence? > > Its about the mapping of the notification payload format. In concrete > terms: SNMPv1 traps are mapped using RFC 3584 to the new format. The > text could probably be more specific. The fine detail here is that an > automatic extraction of "ctxEngine" and "ctxName" out of > SNMPv1/SNMPv2c messages is not possible unless the translator has > access to a mapping table (which might be the case if the translator > is integrated into the management software of a device but once the > translator sits outside the device, this information is usually not > available). Right. From the draft I understood that the 3584 transformation is supposed to be done, but now you write that it might not be possible to do the conversion. So what happens when the snmp-to-syslog translator receives a v1/v2c trap? > > > since a certain percentage of notifications tends > > > to be device/vendor specific and it is unrealistic to assume that an > > > implementation will know all MIB modules. If this is true, then we > > > have to ship OIDs and hex data for certain notifications to the > > > receiver. So one extreme approach is to simply keep the translator > > > dumb and put the burdon on the receiver's side (and it should be > > > fairly easy to write a filter, e.g. an extended version of smixlate, > > > that takes SYSLOG messages and translates OIDs and values into > > > something more human friendly). This is where this document originally > > > started from. > > > > Ok. I think a short note about this should go into the introduction. > > > > But stepping back, is it realistic to assume that an environment > > exists where you can have a syslog server with full MIB knowledge, but > > not have a SNMP trap sink? > > Mappings from SNMP to SYSLOG have been done in the past and I believe > the reasons for having these mappings will persist. Absolutely! > Architecturally, > the SNMP to SYSLOG translator is an SNMP notification receiver (an > SNMP trap sink). So I am not sure I understand your question. My question is if it will be useful to deploy a translator that translates into a "binary" form that a human user cannot understand without a tool that has all MIBs. > > I think that something like this would be useful, and by making it > > optional, the translator can decide if the increased size is > > acceptable or not. > > > > The 'a' parameter seems useful, but in many cases it seems the > > information is redundant - if the receiver does not have MIB > > knowledge, the 'd' parameter is not very useful, but 'a' is. OTOH if > > the receiver has MIB knowledge, the 'd' value can be calculated from > > the 'a' value. As another example, if the type is DisplayString it > > seems like a waste of bytes to send the value as a ascii string *and* > > as a hexstring. > > So you are arguing now against having the 'a' format since it is > redundant? No. I just wonder if it would make sense to drop the other parameter (in the case above drop 'd'), if 'a' is provided. > I like to have a basic format I can rely on being there all > the time. There is already a choice in the grammar for VARVALUE; 'a' could be another choice there. I.e. even in the format in the draft there is no single VARVALUE always present. > If there is additional rendering for human beings, fine. But > I would hate to get something like: > > l="asdf.42" a="boogoo" > > where I have no chance to figure out what it means - is boogoo an enum > or a string value? In the worst case you need MIB knowledge to figure it out, and in the best case you do not need it. With the "binary" encoding you *always* need MIB knowledge. Again, I wonder about the deployment scenario. If all the detailed information is important, don't you typically have a proper SNMP notification receiver? Isn't one reason for existing snmp->syslog translators that the notification gets "readable"? > And what is asdf.42 anyway? I'm sure there are notifications with objects names like this, but to be fair - most objects do have better names than this. /martin From rgerhards@gmail.com Tue Feb 24 07:44:17 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 42A6E3A67B1 for ; Tue, 24 Feb 2009 07:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YEkVrPMhhYG3 for ; Tue, 24 Feb 2009 07:44:16 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 3A60E3A67AE for ; Tue, 24 Feb 2009 07:44:15 -0800 (PST) Received: by fxm11 with SMTP id 11so2884538fxm.13 for ; Tue, 24 Feb 2009 07:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=7MmiNwcmNMIERZpN2Qy2lGQEm5qgeRCpUxU1KJ3HEv8=; b=W9rpwuktd/oTztD1NyKUe3Ha7zGocMzSX/cmfJ5Za8BVb9WwoRtRxy0aYlt/IaVNK0 H/CCzqFxu5TGvku5W+QR4AZat6Dj2KBklPnsZHz1+/ylwGhvsJ9BS6pYz58nEMg+8zKN IgWwgh23+ftC2aT79/bDGAR64O/lJ4Qkf+Zsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=w4s5qK5x6JWPAUklerMLjChKx9QivjuxLusdvOtyt+Z0XUdczj1f4y20jCHynaa3aD s2qZpLLeMJdnIesOSNuFsF2O8hSPvNsAFsT4FF6BkNyyLK49yT8RP0XxLGDCjYF0Pjhx SFLYRFRyiAPKzxIajQcPNpr3aYJqdpX88jjtc= MIME-Version: 1.0 Received: by 10.223.115.12 with SMTP id g12mr7278854faq.92.1235490273959; Tue, 24 Feb 2009 07:44:33 -0800 (PST) Date: Tue, 24 Feb 2009 16:44:33 +0100 Message-ID: From: Rainer Gerhards To: opsawg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00 - truncation 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, 24 Feb 2009 15:44:17 -0000 Finally, I was able to review the work and think it is quite useful. I am following the other discussion threads. There is one thing that I think needs to be spelled out. In syslog, especially with UDP, there is a very limited minimum maximum message size. Especially a human-readable representation of the SNMP notification can easily go beyond that size. The syslog transport sender is permitted to send messages larger than the minimum maximum, in which case a receiver not capable to process the message size can truncate it. But that truncation happens without any semantics, it just drops excess octets. The receiver may also drop the message completely. So this is a somewhat unsecure mode of operations. Alternatively, the sender (inside the snmp-to-syslog translator) may truncate a message if it knows the maximum size to use. Truncation here may be much better, because the sender has the full context and may be able to drop optional elements while still sending the most important information. It may also selectively drop other notification parts, so that at least a fragment of the message will be received by the syslog receiver. Rainer From j.schoenwaelder@jacobs-university.de Tue Feb 24 08:05:02 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 CEAD728B23E for ; Tue, 24 Feb 2009 08:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FRT_POSSIBLE=2.697, 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 AzgMcxsLpdtS for ; Tue, 24 Feb 2009 08:05:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9AAF128C0EB for ; Tue, 24 Feb 2009 08:05:01 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E370C0018; Tue, 24 Feb 2009 17:05:20 +0100 (CET) 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 0vOAnCOIBKhg; Tue, 24 Feb 2009 17:05:13 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53164C0010; Tue, 24 Feb 2009 17:05:13 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 486B69AD49D; Tue, 24 Feb 2009 17:05:12 +0100 (CET) Date: Tue, 24 Feb 2009 17:05:12 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090224160512.GA26471@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , opsawg@ietf.org References: <20090224080020.GA25631@elstar.iuhb02.iu-bremen.de> <20090224.111928.256426913.mbj@tail-f.com> <20090224123331.GB26046@elstar.iuhb02.iu-bremen.de> <20090224.152715.44247666.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224.152715.44247666.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:05:02 -0000 On Tue, Feb 24, 2009 at 03:27:15PM +0100, Martin Bjorklund wrote: > Right. From the draft I understood that the 3584 transformation is > supposed to be done, but now you write that it might not be possible > to do the conversion. So what happens when the snmp-to-syslog > translator receives a v1/v2c trap? I think you are confusing two things and we probably have not done a good job explaining things well: (1) There is the translation of the SNMPv1 trap PDU into RFC 3416 PDU formats. This translation is always posssible and does not require any additional information. So a pointer to RFC 3584 solves this issue. (2) There is the context information that does not exist in SNMPv1/SNMPv2c message formats. While RFC 3584 provides a MIB module that can do this translation, someone has to configure the relevant tables. Since this is not realistic to assume in all translator deployments, we made the context objects optional. Does this make sense now? > My question is if it will be useful to deploy a translator that > translates into a "binary" form that a human user cannot understand > without a tool that has all MIBs. Well, much less binary than BER encoded stuff. ;-) My point is that for some notifications, a generic translator can't do much more than producing hex strings. > No. I just wonder if it would make sense to drop the other parameter > (in the case above drop 'd'), if 'a' is provided. > > > I like to have a basic format I can rely on being there all > > the time. > > There is already a choice in the grammar for VARVALUE; 'a' could be > another choice there. I.e. even in the format in the draft there is > no single VARVALUE always present. This could probably work but needs to be worked out in more detail. So your proposal is to distinguish between rendered strings and enumerations by adding more choices to the enumeration? Or do you think it does not matter to distinguish between the string value "up" and the enum value "up"? Or do you want to keep d= and a= for enums but drop the hexadecimal string only for OCTET STRINGS that have an a= representation? > Again, I wonder about the deployment scenario. If all the detailed > information is important, don't you typically have a proper SNMP > notification receiver? Isn't one reason for existing snmp->syslog > translators that the notification gets "readable"? Perhaps we need to agree on some principles: (i) A translator should not loose information and must no make information carried in a notification message ambiguous. (ii) MIB knowledge is not required by a translator. (iii) A translator with MIB knowledge may generate an improved human readable format as long as (i) and (ii) are met. Do we agree on this? > > And what is asdf.42 anyway? > > I'm sure there are notifications with objects names like this, but to > be fair - most objects do have better names than this. My point was that a label is not a unique identifier and this is why I so far insisted that the OID is always kept and VARLABEL is optionally added for improved human readability. Now for OCTET STRINGS where the translator knows about DISPLAY-HINT rules, I think we can add a special case so that hexadecial representation of the value can be skipped (assuming that the tag of the new string representation indicates that the underlying representation really was on OCTET STRING). So then the question remains what we do about enumerations and bits or OBJECT IDENTIFIER constants. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rgerhards@gmail.com Tue Feb 24 08:17: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 0B2A028C10A for ; Tue, 24 Feb 2009 08:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XSkPt3w6HVon for ; Tue, 24 Feb 2009 08:17:36 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id C41713A6B0A for ; Tue, 24 Feb 2009 08:17:35 -0800 (PST) Received: by bwz5 with SMTP id 5so5920402bwz.13 for ; Tue, 24 Feb 2009 08:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YONh+ms8hzt5WJY2F1Fu3290rn9xDZbFjIn3QIkQocw=; b=Wh3L/vDuRRvcWsuoc+P16c37XOMgn8ACseQENVIvCfl/uvYlIq1SCt2Jo+lGkqETVG Hcg2ShJNrIVLZ1DEkQLnZReuPTEGyZ1tNkouf7/tTISXGiezN13SjlvVDn/+sfbALqnD hu7Xb1753h5j+hhe0fAh0AU3F2jHNpLYBdyLQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pVZad7BkypIlQZZEttxVHIneI7YzIT7OGErOvYN3nF7Z0rEQUXg9/IAho6pa30Lggg UAYyFePSAe7rzEtJydHkMPz71culJdlhDb7HCWKOyPeDKMEwuq+Gre+cggGbhh5TAcCm vds+kcQhviTOeZizlk4LCm4/mKPDywgw3Bfd8= MIME-Version: 1.0 Received: by 10.223.113.136 with SMTP id a8mr17795faq.76.1235492269688; Tue, 24 Feb 2009 08:17:49 -0800 (PST) In-Reply-To: References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> Date: Tue, 24 Feb 2009 17:17:49 +0100 Message-ID: From: Rainer Gerhards To: WashamFan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Tue, 24 Feb 2009 16:17:37 -0000 On Thu, Feb 19, 2009 at 2:52 AM, WashamFan wrote: > Hi, > >> =A0Thinking further; we have the same issue with the order of structured >> =A0data elements. Consider this: >> >> =A0 =A0 [b b=3D"b"][a c=3D"c" a=3D"a"] >> >> =A0We would now get: >> >> =A0 =A0 syslogMsgSDParamValue.1."a".1."c"=3D"c" >> =A0 =A0 syslogMsgSDParamValue.1."a".2."a"=3D"a" >> =A0 =A0 syslogMsgSDParamValue.1."b".1."b"=3D"b" >> >> =A0So perhaps the position needs to be the second index and increment >> =A0across structured data element boundaries: >> >> =A0 =A0 syslogMsgSDParamValue.1.1."b"."b"=3D"b" >> =A0 =A0 syslogMsgSDParamValue.1.2."a"."c"=3D"c" >> =A0 =A0 syslogMsgSDParamValue.1.3."a"."a"=3D"a" >> >> =A0This way, it should be possible to reconstruct all structured data >> =A0elements in the correct order. > > Yes. When we parse SDE, we may take into account where params > position, but SDEs as a whole seems be independent with each other, > I am not sure. But now it is a 1:1 mapping from syslog SDEs to > syslogMsgSDTable entries, I think;) SDEs, by concept, do not necessarily have a specific order. They shall be addressed by the SD-ID and not by order of appearance. This permits several elements in a syslog chain (e.g. before the message is put on the wire for the first time) to add parameters. The order of params inside the SDE is actually not mandated. One may argue that this should have been specified, but it has not. So the spirit of syslog-transport was that equally named params form a set of values, where order of appearance is irrelevant. Thus there is only very brief text on it: "A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT." Rainer From rgerhards@gmail.com Tue Feb 24 08:23: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 CEBFD3A683E for ; Tue, 24 Feb 2009 08:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 CBXSl2l-XVY0 for ; Tue, 24 Feb 2009 08:23:48 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id C7FC13A67EA for ; Tue, 24 Feb 2009 08:23:47 -0800 (PST) Received: by bwz5 with SMTP id 5so5925500bwz.13 for ; Tue, 24 Feb 2009 08:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4xwpnEl/woyGZhqbPs0X5AMSxaafit8jJrctl8DQxEg=; b=es6dDQw2EaKMGAMFevgRgze3b44Qw64dC4f6AkdktKjxT6oGxelfDRezn+EoGMu61o HBWF0XeloUKpX/ns5BL5xh1SESdMAngDp1b/27h3jpLPUUod4du9W+3cC/Ws0r1Q9xL2 x2MPi5bIf+CXo5RwOQpKeuSocg25jN1dIsFL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=i6XNn+495Bsq9KUm83XzA2KTruTiyEiFMbq7GkKD5Vs0JHh4a1wL/me+eCvfEfxbgW fcI60YUd62MBJwzoze3MkAQRLskXvIDdmG4kQ7YCJJR5pPXoYF2iq5yThwB2AOe73qJa Q31NFPB6Qt936mCHXM/J5TlrojL0RS10TLaqA= MIME-Version: 1.0 Received: by 10.223.119.198 with SMTP id a6mr12341far.42.1235492643373; Tue, 24 Feb 2009 08:24:03 -0800 (PST) In-Reply-To: <20090224160512.GA26471@elstar.iuhb02.iu-bremen.de> References: <20090224080020.GA25631@elstar.iuhb02.iu-bremen.de> <20090224.111928.256426913.mbj@tail-f.com> <20090224123331.GB26046@elstar.iuhb02.iu-bremen.de> <20090224.152715.44247666.mbj@tail-f.com> <20090224160512.GA26471@elstar.iuhb02.iu-bremen.de> Date: Tue, 24 Feb 2009 17:24:03 +0100 Message-ID: From: Rainer Gerhards To: j.schoenwaelder@jacobs-university.de, Martin Bjorklund , opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00 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, 24 Feb 2009 16:23:48 -0000 On Tue, Feb 24, 2009 at 5:05 PM, Juergen Schoenwaelder wrote: > On Tue, Feb 24, 2009 at 03:27:15PM +0100, Martin Bjorklund wrote: >> My question is if it will be useful to deploy a translator that >> translates into a "binary" form that a human user cannot understand >> without a tool that has all MIBs. > > Well, much less binary than BER encoded stuff. ;-) My point is that > for some notifications, a generic translator can't do much more than > producing hex strings. As someone who does such generic translators today, I agree to Juergen's point. There are always cases left where you need to stuff a hex string into the message because you do not know enough to do anything else. Rainer From j.schoenwaelder@jacobs-university.de Tue Feb 24 08:28:14 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 C6DBB3A683E for ; Tue, 24 Feb 2009 08:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 oaR+Y3dqQteG for ; Tue, 24 Feb 2009 08:28:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 87C193A67EA for ; Tue, 24 Feb 2009 08:28:13 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7479BC0010; Tue, 24 Feb 2009 17:28:32 +0100 (CET) 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 vspITImxsdC7; Tue, 24 Feb 2009 17:28:26 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25A3FC0068; Tue, 24 Feb 2009 17:28:26 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 118B69AD641; Tue, 24 Feb 2009 17:28:25 +0100 (CET) Date: Tue, 24 Feb 2009 17:28:24 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Message-ID: <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Rainer Gerhards , WashamFan , opsawg@ietf.org References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> 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: WashamFan , opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:28:14 -0000 On Tue, Feb 24, 2009 at 05:17:49PM +0100, Rainer Gerhards wrote: > SDEs, by concept, do not necessarily have a specific order. They shall > be addressed by the SD-ID and not by order of appearance. This permits > several elements in a syslog chain (e.g. before the message is put on > the wire for the first time) to add parameters. OK. But once the message has been sent the first time, the order is not expected to change, right? > The order of params inside the SDE is actually not mandated. One may > argue that this should have been specified, but it has not. So the > spirit of syslog-transport was that equally named params form a set of > values, where order of appearance is irrelevant. Thus there is only > very brief text on it: > > "A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT." Fine. The MIB currently preserves the order and it turned out that doing so actually comes almost for free by just changing the INDEX order and the semantics of one index component. So the MIB kind of preserves the order as it was in the original message once it did hit the wire. We were probably not required to do this but I believe it is a feature that we can preserve the order. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rgerhards@gmail.com Tue Feb 24 08:29:12 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 933433A6AA5 for ; Tue, 24 Feb 2009 08:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 h6D6pZt8QdzJ for ; Tue, 24 Feb 2009 08:29:11 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id A373C3A6A9B for ; Tue, 24 Feb 2009 08:29:11 -0800 (PST) Received: by fxm11 with SMTP id 11so2923649fxm.13 for ; Tue, 24 Feb 2009 08:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=T1KuRl+gLEEF005nnZlWtKyDiHVur/xuGrWf/ZLMWqo=; b=SiMPQrxrJvAXKTHf3lTCJyibKtafVzFDB0k3va+RernE7AlWzSwI6SBcCwE0YDZdh2 4U8PyJTWau9YIbrAionM7jR1g6N6K+oqPSWZam3SqXyGo1Cx1UhsP6+betd7K74x5vIa 2DDhGkIgBRcWaQSWrwn8x+/1Az/5GfkH8TNdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=shC5m/2bO3uBUf8Zutvg1jO2G45WNvj01Kw+Jd+v8xei94hc+lNpS2rqH7AtYjbWw/ T0MOS9FuaRNSrQNJ35UM0jrfyeOYKU6c3GBZBGABtr2rqqdeoqQhAV4B6Z1E4wq0EcRE OGmhWCTZAaZtsNhA/G/eek8hUDVD8BHIvZ6Pg= MIME-Version: 1.0 Received: by 10.223.107.199 with SMTP id c7mr21084fap.31.1235492969316; Tue, 24 Feb 2009 08:29:29 -0800 (PST) Date: Tue, 24 Feb 2009 17:29:29 +0100 Message-ID: From: Rainer Gerhards To: opsawg , j.schoenwaelder@jacobs-university.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] syslog-msg-mib & opsawg-syslog-snmp 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, 24 Feb 2009 16:29:12 -0000 I wonder if a provision should be made in syslog-msg-mib that the original notification should be restored if the syslog message received is in the format specificed by syslog-snmp. That could be the case if - for whatever reasons - a SNMP notification is tunneled over a syslog link. While this sounds unrealistic, it may be useful to at least provide a hint what to do in such cases. Rainer From j.schoenwaelder@jacobs-university.de Tue Feb 24 08:36:07 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 301603A6AF5 for ; Tue, 24 Feb 2009 08:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 9qU6Y1W6COHO for ; Tue, 24 Feb 2009 08:36:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 214723A683E for ; Tue, 24 Feb 2009 08:36:06 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14C36C00DF; Tue, 24 Feb 2009 17:36:25 +0100 (CET) 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 z+SKecRh4igl; Tue, 24 Feb 2009 17:36:19 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 130BEC0010; Tue, 24 Feb 2009 17:36:19 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id F381F9AD6C2; Tue, 24 Feb 2009 17:36:17 +0100 (CET) Date: Tue, 24 Feb 2009 17:36:17 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Message-ID: <20090224163617.GA26621@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Rainer Gerhards , opsawg References: 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 Subject: Re: [OPSAWG] syslog-msg-mib & opsawg-syslog-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:36:07 -0000 On Tue, Feb 24, 2009 at 05:29:29PM +0100, Rainer Gerhards wrote: > I wonder if a provision should be made in syslog-msg-mib that the > original notification should be restored if the syslog message > received is in the format specificed by syslog-snmp. That could be the > case if - for whatever reasons - a SNMP notification is tunneled over > a syslog link. While this sounds unrealistic, it may be useful to at > least provide a hint what to do in such cases. There is also the other case of a SYSLOG message tunneled over an SNMP notification link. Yes, it may sounds strange for most people to think about such constructions but I would not be surprised if people find reasons to deploy such things, especially if notifications have to cross organizational boundaries and different tool chains. So far there is no text about these situations in the documents but part of my argumentation on this list for having translations that do not loose information stems from the fact that I like to have reversible translations that will work in such scenarios. Perhaps we should make this explicit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rgerhards@gmail.com Tue Feb 24 08:43: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 6E9093A6A51 for ; Tue, 24 Feb 2009 08:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Zd3ZMec8dHre for ; Tue, 24 Feb 2009 08:43:41 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 273243A6804 for ; Tue, 24 Feb 2009 08:43:40 -0800 (PST) Received: by bwz5 with SMTP id 5so5942002bwz.13 for ; Tue, 24 Feb 2009 08:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Ey7/txYp0uL2uuwGS7DBiAqt/OkkfvJ1CbVSemlScwY=; b=C/AKyicgvXsrBGg7+Cl8VMGHUgoTD6G5F/zF2IQH6WNuAFYxrgRPENu7BddpNHmbpZ ohA1jX95Fwg510EdipCdHeyXEfV89D1ZsQS85bRFR4xuqj7OjyzNJAMvrbZDi6x2kBO8 wznbakBF9mjtVVPsQmciaYytMbKzmHuXzt6og= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ox9EDKYjEd3Rv4gjOg9gLSpmqhl1KiTW3p26mtOKqNXS+lERb2TCVIb02qmNrAxnfq MXZe9Fk04HDtvwRWtSoesC+VGPFdroXTDyRdqXiecC5pboYvfH1qboENVTWGvwYnFXuL 8xIlMvLNv9SmohZxlI8a9fRryYYeJas/r6uoQ= MIME-Version: 1.0 Received: by 10.223.115.195 with SMTP id j3mr1904faq.99.1235493835879; Tue, 24 Feb 2009 08:43:55 -0800 (PST) In-Reply-To: <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> Date: Tue, 24 Feb 2009 17:43:55 +0100 Message-ID: From: Rainer Gerhards To: j.schoenwaelder@jacobs-university.de, Rainer Gerhards , WashamFan , opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Tue, 24 Feb 2009 16:43:42 -0000 On Tue, Feb 24, 2009 at 5:28 PM, Juergen Schoenwaelder wrote: > On Tue, Feb 24, 2009 at 05:17:49PM +0100, Rainer Gerhards wrote: > >> SDEs, by concept, do not necessarily have a specific order. They shall >> be addressed by the SD-ID and not by order of appearance. This permits >> several elements in a syslog chain (e.g. before the message is put on >> the wire for the first time) to add parameters. > > OK. But once the message has been sent the first time, the order is > not expected to change, right? "not expected" is good wording here. syslog-protocol permits relays to modify messages, what includes modification on the order of SDEs. But it also cautions against doing so. The spelled-out case is that digital signatures (hashes) may be invalidated. However, there may be some cases where message modifications, and especially SDE modifications, may happen. The dominant case that comes up my minds is relays that record (inside the message) that the message was passed over this relay. This, if done, is expected to happen to the SDE. The reason such behavior was not outruled is that syslog is simplex. So we do not have any other way to convey that information. At least not with all transports. It can not be done with -transport-udp and also not with -transport-tls. RFC3195 provides a mechanism to convey message path information, but it is not widely accepted. RFC3195bis will probably keep that ability. Currently existing implementations tend to add message path information by modifying the syslog message, so we can expect this will happen in the future, too. Thinking in the context of syslog-msg-mib, I would expect that all of this happened before the message hits the translator (but not necessarily before hitting the wire). If I now assume that a translated message will be re-emitted as syslog message (after "snmp tunneling"), the order would be correctly reconstructed, which is well within the recommendations of syslog-protocol. So this is probably the best thing to do. >> The order of params inside the SDE is actually not mandated. One may >> argue that this should have been specified, but it has not. So the >> spirit of syslog-transport was that equally named params form a set of >> values, where order of appearance is irrelevant. Thus there is only >> very brief text on it: >> >> "A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT." > > Fine. The MIB currently preserves the order and it turned out that > doing so actually comes almost for free by just changing the INDEX > order and the semantics of one index component. So the MIB kind of > preserves the order as it was in the original message once it did hit > the wire. We were probably not required to do this but I believe it is > a feature that we can preserve the order. I fully agree, this is a good way to handle the situation. Rainer From rgerhards@gmail.com Tue Feb 24 08:53:51 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 65AD93A69ED for ; Tue, 24 Feb 2009 08:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6rWRnNCqf+1y for ; Tue, 24 Feb 2009 08:53:50 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 9DC443A659C for ; Tue, 24 Feb 2009 08:53:49 -0800 (PST) Received: by fxm11 with SMTP id 11so2943896fxm.13 for ; Tue, 24 Feb 2009 08:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=6ATJ/MJpJt9H9V4KLN2IhqvKSClwJE+ppWy3b2xwNd0=; b=b/gfrR0j8nEpsBPDb/cT0uq5+rfQku0mSrMj/ck0IymDV+W07lyCHMYz0AdQ4JAS+j +jR1YbTAPLy0LeyTb53v73d69ETWn923lgVkVD96lM7ZJArLSuSgC9qLkcElE0JCpX5Z aaDhvyGEyN1TYBnu29ECQGbfIfsvRzClVF23o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=LY/pkqkPUhYuQrp0cVqJX+gaJ4ja6M74kZShzmFea1UZRZbfJNT3f2cY9mv3Q8TWH4 eI9FJZqiV1gOUgMlDer6IEqtk05cbyAGoXYOr4IZK2PniJhfUTIuARwBv+Ppq2gtE3Mj BYrUlfghUUpbpMdotCcJ3CUQe5/EntvvW0luE= MIME-Version: 1.0 Received: by 10.223.106.200 with SMTP id y8mr10524fao.24.1235494445655; Tue, 24 Feb 2009 08:54:05 -0800 (PST) In-Reply-To: <20090224163617.GA26621@elstar.iuhb02.iu-bremen.de> References: <20090224163617.GA26621@elstar.iuhb02.iu-bremen.de> Date: Tue, 24 Feb 2009 17:54:05 +0100 Message-ID: From: Rainer Gerhards To: j.schoenwaelder@jacobs-university.de, Rainer Gerhards , opsawg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] syslog-msg-mib & opsawg-syslog-snmp 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, 24 Feb 2009 16:53:51 -0000 On Tue, Feb 24, 2009 at 5:36 PM, Juergen Schoenwaelder wrote: > On Tue, Feb 24, 2009 at 05:29:29PM +0100, Rainer Gerhards wrote: > >> I wonder if a provision should be made in syslog-msg-mib that the >> original notification should be restored if the syslog message >> received is in the format specificed by syslog-snmp. That could be the >> case if - for whatever reasons - a SNMP notification is tunneled over >> a syslog link. While this sounds unrealistic, it may be useful to at >> least provide a hint what to do in such cases. > > There is also the other case of a SYSLOG message tunneled over an SNMP > notification link. Yes, it may sounds strange for most people to think > about such constructions but I would not be surprised if people find > reasons to deploy such things, especially if notifications have to > cross organizational boundaries and different tool chains. > > So far there is no text about these situations in the documents but > part of my argumentation on this list for having translations that do > not loose information stems from the fact that I like to have > reversible translations that will work in such scenarios. Perhaps we > should make this explicit. I think making it explicit would be useful. Rainer From ietfdbh@comcast.net Tue Feb 24 09:28:15 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 8A5443A6B3D for ; Tue, 24 Feb 2009 09:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 682IBqXt62Vf for ; Tue, 24 Feb 2009 09:28:14 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 502CC3A6A1A for ; Tue, 24 Feb 2009 09:27:59 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Kqmd1b00B0vyq2s58tUKQU; Tue, 24 Feb 2009 17:28:19 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id KtUJ1b00X0UQ6dC3RtUJti; Tue, 24 Feb 2009 17:28:19 +0000 From: "David Harrington" To: "'Martin Bjorklund'" , References: <20090223.215409.145407580.mbj@tail-f.com><20090224080020.GA25631@elstar.iuhb02.iu-bremen.de> <20090224.111928.256426913.mbj@tail-f.com> Date: Tue, 24 Feb 2009 12:28:17 -0500 Message-ID: <095901c996a5$484c73f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090224.111928.256426913.mbj@tail-f.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmWaWUtEU1v5227TLmh6/qSRFXe9wAMTsaw Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00 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, 24 Feb 2009 17:28:15 -0000 > In general, we assume that notifications from an SNMP version > preceding SNMPv3 are mapped into the notification format used by > SNMPv3 according to the coexistance rules defined in RFC 3584 > [RFC3584]. > > After translation, each notification will have a contextEngineID and > contextName. Otherwise, what is the point of this sentence? I think that converging them into a common format makes sense, and since that conversion is already defined in RFC3584, it makes sense to use that. > > But stepping back, is it realistic to assume that an environment > exists where you can have a syslog server with full MIB knowledge, but > not have a SNMP trap sink? As I think about this, I envision devices only capable of sending syslog messages to a syslog receiver. But at the syslog receiver, having a translator to a local SNMP engine (which might also be a trap sink for devices that can send traps.) One advantage I can see is congestion control and possible application acknowledgement. Syslog has no acknowledgements, but SNMP does. So if a syslog message is sent to a syslog receiver, translated into SNMP, and then sent as an Inform, then you more-or-less add acknowledgements to syslog. Granted, the acknowledgement does not go to the syslog originator, but converting from syslog to Informs means you can provide better congestion control between the translator/forwarder and the trap sink. If the syslog messages are not received over the wire, but are "sent" to local logs, then you could have a situation where you have syslog support and SNMP support on the same device, and use the converter between daemons, to handle, device drivers that only speak syslog, but you can convert those to SNMP Informs which gives you system-level acks, even if the device driver doesn't get the ack. Given such an ack, you can suppress resends of syslog messages, in much the same way Informs allow you to limit resends better than traps. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From Washam.Fan@huaweisymantec.com Tue Feb 24 19:52: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 75A453A67B2 for ; Tue, 24 Feb 2009 19:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.591, 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 ECPf+aRTdX4f for ; Tue, 24 Feb 2009 19:52:42 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 4ECD83A69BA for ; Tue, 24 Feb 2009 19:52:42 -0800 (PST) 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 <0KFL006SIS48J520@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 25 Feb 2009 11:52:58 +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 <0KFL00C51S46VO00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 25 Feb 2009 11:52:56 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 25 Feb 2009 11:52:54 +0800 From: WashamFan To: Rainer Gerhards Message-id: Date: Wed, 25 Feb 2009 11:52:54 +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: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 25 Feb 2009 03:52:43 -0000 Hi, The new indexing schema make sure 1:1 mapping between syslog SD parameters and SDTable entries. When reconstructing syslog SDEs from SDTable entries, no infomation is lost. Take a look at snmp SDE which is defined in syslog-snmp-00, interpretation of this SDE heavily depends on the order of SD parameters. washam > On Tue, Feb 24, 2009 at 5:28 PM, Juergen Schoenwaelder > wrote: > > On Tue, Feb 24, 2009 at 05:17:49PM +0100, Rainer Gerhards wrote: > > > >> SDEs, by concept, do not necessarily have a specific order. They shall > >> be addressed by the SD-ID and not by order of appearance. This permits > >> several elements in a syslog chain (e.g. before the message is put > on > >> the wire for the first time) to add parameters. > > > > OK. But once the message has been sent the first time, the order is > > not expected to change, right? > > "not expected" is good wording here. syslog-protocol permits relays to > modify messages, what includes modification on the order of SDEs. But > it also cautions against doing so. The spelled-out case is that > digital signatures (hashes) may be invalidated. > > However, there may be some cases where message modifications, and > especially SDE modifications, may happen. The dominant case that comes > up my minds is relays that record (inside the message) that the > message was passed over this relay. This, if done, is expected to > happen to the SDE. > > The reason such behavior was not outruled is that syslog is simplex. > So we do not have any other way to convey that information. At least > not with all transports. It can not be done with -transport-udp and > also not with -transport-tls. RFC3195 provides a mechanism to convey > message path information, but it is not widely accepted. RFC3195bis > will probably keep that ability. > > Currently existing implementations tend to add message path > information by modifying the syslog message, so we can expect this > will happen in the future, too. > > Thinking in the context of syslog-msg-mib, I would expect that all of > this happened before the message hits the translator (but not > necessarily before hitting the wire). If I now assume that a > translated message will be re-emitted as syslog message (after "snmp > tunneling"), the order would be correctly reconstructed, which is well > within the recommendations of syslog-protocol. So this is probably the > best thing to do. > > >> The order of params inside the SDE is actually not mandated. One may > >> argue that this should have been specified, but it has not. So the > >> spirit of syslog-transport was that equally named params form a > set of > >> values, where order of appearance is irrelevant. Thus there is only > >> very brief text on it: > >> > >> "A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT." > > > > Fine. The MIB currently preserves the order and it turned out that > > doing so actually comes almost for free by just changing the INDEX > > order and the semantics of one index component. So the MIB kind of > > preserves the order as it was in the original message once it did hit > > the wire. We were probably not required to do this but I believe it > is > > a feature that we can preserve the order. > > I fully agree, this is a good way to handle the situation. > > Rainer > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From Washam.Fan@huaweisymantec.com Tue Feb 24 20:03: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 A9BBC3A67DD for ; Tue, 24 Feb 2009 20:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532, 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 GLbFOZT1SPf5 for ; Tue, 24 Feb 2009 20:03:37 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 84E7A3A67CF for ; Tue, 24 Feb 2009 20:03:37 -0800 (PST) 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 <0KFL00L9RSMF7R20@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 25 Feb 2009 12:03:54 +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 <0KFL00B9BSMCF800@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 25 Feb 2009 12:03:50 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 25 Feb 2009 12:03:48 +0800 From: WashamFan To: Rainer Gerhards Message-id: Date: Wed, 25 Feb 2009 12:03: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: References: <20090224163617.GA26621@elstar.iuhb02.iu-bremen.de> Cc: opsawg Subject: Re: [OPSAWG] syslog-msg-mib & opsawg-syslog-snmp 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, 25 Feb 2009 04:03:38 -0000 Hi, Juergen Are you sure reversible translations are not loosing infomation? If yes, it is not necessary to state explicitly tunnel cases. Anyway, I can live with that. washam > On Tue, Feb 24, 2009 at 5:36 PM, Juergen Schoenwaelder > wrote: > > On Tue, Feb 24, 2009 at 05:29:29PM +0100, Rainer Gerhards wrote: > > > >> I wonder if a provision should be made in syslog-msg-mib that the > >> original notification should be restored if the syslog message > >> received is in the format specificed by syslog-snmp. That could be > the > >> case if - for whatever reasons - a SNMP notification is tunneled over > >> a syslog link. While this sounds unrealistic, it may be useful to > at > >> least provide a hint what to do in such cases. > > > > There is also the other case of a SYSLOG message tunneled over an SNMP > > notification link. Yes, it may sounds strange for most people to think > > about such constructions but I would not be surprised if people find > > reasons to deploy such things, especially if notifications have to > > cross organizational boundaries and different tool chains. > > > > So far there is no text about these situations in the documents but > > part of my argumentation on this list for having translations that > do > > not loose information stems from the fact that I like to have > > reversible translations that will work in such scenarios. Perhaps we > > should make this explicit. > > I think making it explicit would be useful. > > Rainer > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From Washam.Fan@huaweisymantec.com Tue Feb 24 21:09: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 D2AD93A67E9 for ; Tue, 24 Feb 2009 21:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.484, 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 GbgnzI3yFx9K for ; Tue, 24 Feb 2009 21:09:20 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id DF59A3A6A3D for ; Tue, 24 Feb 2009 21:09:19 -0800 (PST) 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 <0KFL00LPFVNZ7R20@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 25 Feb 2009 13:09:37 +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 <0KFL003QSVNYI300@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 25 Feb 2009 13:09:35 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 25 Feb 2009 13:09:34 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Wed, 25 Feb 2009 13:09:34 +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: <20090223072526.GA23980@elstar.iuhb02.iu-bremen.de> References: <20090219115857.GC12569@elstar.iuhb02.iu-bremen.de> <20090223072526.GA23980@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgNotification, syslog-msg-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: Wed, 25 Feb 2009 05:09:20 -0000 Hi, I am a still confused about this. I am not a SNMP expert, you know, so maybe I missed something I don't know. See below. > On Mon, Feb 23, 2009 at 03:15:24PM +0800, WashamFan wrote: > > > So there are some assumptions: > > 1) At least one syslogMsgSDParamValue exists in notification, what > if there > > is no syslogMsgSDParamValue but sdparams bit is set? > > You can still construct a GetNext with syslogMsgSDParamIndex=0. Yes I can start syslogMsgSDParamIndex with 0, but I have no idea what values of 'syslogMsgSDElementName' and 'syslogMsgSDParamName' are. If I initiate a request like: GetNextRequest ( syslogMsgSDParamValue.X.0) Could it return like: Response ( syslogMsgSDParamValue.X.0."some"."thing"="value" ) ? > > In your example, you getnext until you get something that does not > belong > > to the syslog message in question. What does 'somthing' refer to? > next entry > > belonging to another syslogMsgIndex or access control denied error? > > GetNext never returs an access control denied error. You iterate until > you get something that does not belong to the syslog message in > question - it might be a syslogMsgSDParamName of a different syslog > message or something completely different. You iterate until something belonging to a different syslog message, is it relevant to access control? What if 'something' here is not supposed to be red by you? washam From ietfdbh@comcast.net Tue Feb 24 21:58:06 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 D26843A6B31 for ; Tue, 24 Feb 2009 21:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 TBnLQ-jeLFAN for ; Tue, 24 Feb 2009 21:58:04 -0800 (PST) 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 5A30A3A6AC9 for ; Tue, 24 Feb 2009 21:58:04 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA04.westchester.pa.mail.comcast.net with comcast id L5vG1b0070ldTLk545yQai; Wed, 25 Feb 2009 05:58:24 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id L5yP1b00L0UQ6dC3Q5yQEc; Wed, 25 Feb 2009 05:58:24 +0000 From: "David Harrington" To: "'WashamFan'" , References: <20090219115857.GC12569@elstar.iuhb02.iu-bremen.de><20090223072526.GA23980@elstar.iuhb02.iu-bremen.de> Date: Wed, 25 Feb 2009 00:58:22 -0500 Message-ID: <0a5601c9970e$11a78f60$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmXB0Z+Sx5er9giStiq3A7FCIgTcAABSexQ Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgNotification, syslog-msg-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: Wed, 25 Feb 2009 05:58:06 -0000 Hi, If you are not allowed to access it, it will not be returned; it will go to the next thing you can see. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of WashamFan > Sent: Wednesday, February 25, 2009 12:10 AM > To: j.schoenwaelder@jacobs-university.de > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] syslogMsgNotification, syslog-msg-mib-01 > > Hi, > > I am a still confused about this. I am not a SNMP > expert, you know, so maybe I missed something I don't know. > > See below. > > > On Mon, Feb 23, 2009 at 03:15:24PM +0800, WashamFan wrote: > > > > > So there are some assumptions: > > > 1) At least one syslogMsgSDParamValue exists in > notification, what > > if there > > > is no syslogMsgSDParamValue but sdparams bit is set? > > > > You can still construct a GetNext with syslogMsgSDParamIndex=0. > > Yes I can start syslogMsgSDParamIndex with 0, but I have no idea > what values of 'syslogMsgSDElementName' and 'syslogMsgSDParamName' > are. If I initiate a request like: > GetNextRequest ( syslogMsgSDParamValue.X.0) > Could it return like: > Response ( syslogMsgSDParamValue.X.0."some"."thing"="value" ) > ? > > > > > In your example, you getnext until you get something > that does not > > belong > > > to the syslog message in question. What does 'somthing' > refer to? > > next entry > > > belonging to another syslogMsgIndex or access control > denied error? > > > > GetNext never returs an access control denied error. You > iterate until > > you get something that does not belong to the syslog message in > > question - it might be a syslogMsgSDParamName of a different syslog > > message or something completely different. > > You iterate until something belonging to a different syslog > message, is it > relevant to access control? What if 'something' here is not > supposed to > be red by you? > > washam > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From rgerhards@gmail.com Wed Feb 25 00:56: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 297C53A686C for ; Wed, 25 Feb 2009 00:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Tvolcf17ugTF for ; Wed, 25 Feb 2009 00:56:25 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id E6D033A6781 for ; Wed, 25 Feb 2009 00:56:24 -0800 (PST) Received: by fxm11 with SMTP id 11so3561219fxm.13 for ; Wed, 25 Feb 2009 00:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TW0/hYcLq5Ps/aSl5/He++0xSjBVfS1S0gkUnFin+M4=; b=k0ro6vgIHnmkNItFmuGoSgvfKQaM5ps8Ke8adpU6KdfeuoDOh8NBXy9zNmghTBClLe +RTJp3XTim0r4PHonRs5pJ8qDl2ja48tVaThaPEZ2y5LqC4jL7JlROyGGjHjDBplG7Mn xas40WhMUqLiscu0yDUWbIjyvYoRmOctDTozY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ImymKBVugTddABiKRal1VOuQbVcbUpCfr04WW4KhKJGvBsxHfa9PwOMuqwvQGAVBFJ fUcjydTshMlHHurrQ8Oi8qhjlaOaaCLQ3p4Z4Sq0v6eq2savRN4W2+q4FhByIE5eCDS3 GSXmlK5wP7GOJ3OwV/V3DyKPn/kQYudQqwQoU= MIME-Version: 1.0 Received: by 10.180.224.6 with SMTP id w6mr253180bkg.63.1235552203061; Wed, 25 Feb 2009 00:56:43 -0800 (PST) In-Reply-To: References: <20090224163617.GA26621@elstar.iuhb02.iu-bremen.de> Date: Wed, 25 Feb 2009 09:56:42 +0100 Message-ID: From: Rainer Gerhards To: WashamFan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsawg Subject: Re: [OPSAWG] syslog-msg-mib & opsawg-syslog-snmp 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, 25 Feb 2009 08:56:26 -0000 On Wed, Feb 25, 2009 at 5:03 AM, WashamFan wrote: > Hi, Juergen > > Are you sure reversible translations are not loosing infomation? I think this can not be outruled, at least least in the snmp -> syslog -> snmp case. The reason here is that syslog message size constraints may cause loss of some elements. That's also the reason why I think it would be useful to state this use case explicitly, this enables us to specify some constraints. Rainer > If yes, it is not necessary to state explicitly tunnel cases. > Anyway, I can live with that. > > washam > >> On Tue, Feb 24, 2009 at 5:36 PM, Juergen Schoenwaelder >> =A0 wrote: >> =A0> On Tue, Feb 24, 2009 at 05:29:29PM +0100, Rainer Gerhards wrote: >> =A0> >> =A0>> I wonder if a provision should be made in syslog-msg-mib that the >> =A0>> original notification should be restored if the syslog message >> =A0>> received is in the format specificed by syslog-snmp. That could be >> the >> =A0>> case if - for whatever reasons - a SNMP notification is tunneled o= ver >> =A0>> a syslog link. While this sounds unrealistic, it may be useful to >> at >> =A0>> least provide a hint what to do in such cases. >> =A0> >> =A0> There is also the other case of a SYSLOG message tunneled over an S= NMP >> =A0> notification link. Yes, it may sounds strange for most people to th= ink >> =A0> about such constructions but I would not be surprised if people fin= d >> =A0> reasons to deploy such things, especially if notifications have to >> =A0> cross organizational boundaries and different tool chains. >> =A0> >> =A0> So far there is no text about these situations in the documents but >> =A0> part of my argumentation on this list for having translations that >> do >> =A0> not loose information stems from the fact that I like to have >> =A0> reversible translations that will work in such scenarios. Perhaps w= e >> =A0> should make this explicit. >> >> =A0I think making it explicit would be useful. >> >> =A0Rainer >> =A0_______________________________________________ >> =A0OPSAWG mailing list >> =A0OPSAWG@ietf.org >> =A0https://www.ietf.org/mailman/listinfo/opsawg >> > From rgerhards@gmail.com Wed Feb 25 00:58:36 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 CFA9E3A68E7 for ; Wed, 25 Feb 2009 00:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Big8kIrUdFQ2 for ; Wed, 25 Feb 2009 00:58:35 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 5D1413A67E7 for ; Wed, 25 Feb 2009 00:58:35 -0800 (PST) Received: by bwz5 with SMTP id 5so6555779bwz.13 for ; Wed, 25 Feb 2009 00:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sFa7v/u3yfG5ucCbv3h8PjS5rpvmCYZtvj2VJUMk1Po=; b=MaptO6oUAQjZtnF0EVZmo2enjZ0xrqE3Goz/rsBjWXI5+s6kfB622mW4AMuiodZMns Lv+Ofv+IDPFYAzsJjz8fUEJdALxzy//px8wA5Hfah4ydeXmA7gPFN7euiVGfF+a9NdVX Kcg8TXrn81R5yyJt5mCT68n8PyMhBUI7LgJiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uDi92IYzejShrKc8kNgMmSGsBszeDjBRNx9lGhjlm9Jvq9DYo+XHz5d5Nw45QHSMwG jUCmB26z8c5fhPyEczbbxOxm5eQs38E1Zn1UtKG5gBXh7G95YEVVKhnwcR4usLS5nAwB WfzQkkC08eXDd8go5dUpaA1VG3VnEszdl0KDQ= MIME-Version: 1.0 Received: by 10.181.197.6 with SMTP id z6mr252147bkp.213.1235552334370; Wed, 25 Feb 2009 00:58:54 -0800 (PST) In-Reply-To: References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> Date: Wed, 25 Feb 2009 09:58:54 +0100 Message-ID: From: Rainer Gerhards To: WashamFan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 25 Feb 2009 08:58:36 -0000 On Wed, Feb 25, 2009 at 4:52 AM, WashamFan wrote: > Hi, > > The new indexing schema make sure 1:1 mapping between > syslog SD parameters and SDTable entries. When reconstructing > syslog SDEs from SDTable entries, no infomation is lost. > Take a look at snmp SDE which is defined in syslog-snmp-00, > interpretation of this SDE heavily depends on the order of > SD parameters. Yes, and this is why I commented. In theory, a syslog relay may reorder elements. I do not expect any such implementation in practice (other than those I pointed out), but still one could argue that it is valid to do so. Rainer > > washam > >> On Tue, Feb 24, 2009 at 5:28 PM, Juergen Schoenwaelder >> =A0 wrote: >> =A0> On Tue, Feb 24, 2009 at 05:17:49PM +0100, Rainer Gerhards wrote: >> =A0> >> =A0>> SDEs, by concept, do not necessarily have a specific order. They s= hall >> =A0>> be addressed by the SD-ID and not by order of appearance. This per= mits >> =A0>> several elements in a syslog chain (e.g. before the message is put >> on >> =A0>> the wire for the first time) to add parameters. >> =A0> >> =A0> OK. But once the message has been sent the first time, the order is >> =A0> not expected to change, right? >> >> =A0"not expected" is good wording here. syslog-protocol permits relays t= o >> =A0modify messages, what includes modification on the order of SDEs. But >> =A0it also cautions against doing so. The spelled-out case is that >> =A0digital signatures (hashes) may be invalidated. >> >> =A0However, there may be some cases where message modifications, and >> =A0especially SDE modifications, may happen. The dominant case that come= s >> =A0up my minds is relays that record (inside the message) that the >> =A0message was passed over this relay. This, if done, is expected to >> =A0happen to the SDE. >> >> =A0The reason such behavior was not outruled is that syslog is simplex. >> =A0So we do not have any other way to convey that information. At least >> =A0not with all transports. It can not be done with -transport-udp and >> =A0also not with -transport-tls. RFC3195 provides a mechanism to convey >> =A0message path information, but it is not widely accepted. RFC3195bis >> =A0will probably keep that ability. >> >> =A0Currently existing implementations tend to add message path >> =A0information by modifying the syslog message, so we can expect this >> =A0will happen in the future, too. >> >> =A0Thinking in the context of syslog-msg-mib, I would expect that all of >> =A0this happened before the message hits the translator (but not >> =A0necessarily before hitting the wire). If I now assume that a >> =A0translated message will be re-emitted as syslog message (after "snmp >> =A0tunneling"), the order would be correctly reconstructed, which is wel= l >> =A0within the recommendations of syslog-protocol. So this is probably th= e >> =A0best thing to do. >> >> =A0>> The order of params inside the SDE is actually not mandated. One m= ay >> =A0>> argue that this should have been specified, but it has not. So the >> =A0>> spirit of syslog-transport was that equally named params form a >> set of >> =A0>> values, where order of appearance is irrelevant. Thus there is onl= y >> =A0>> very brief text on it: >> =A0>> >> =A0>> "A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT." >> =A0> >> =A0> Fine. The MIB currently preserves the order and it turned out that >> =A0> doing so actually comes almost for free by just changing the INDEX >> =A0> order and the semantics of one index component. So the MIB kind of >> =A0> preserves the order as it was in the original message once it did h= it >> =A0> the wire. We were probably not required to do this but I believe it >> is >> =A0> a feature that we can preserve the order. >> >> =A0I fully agree, this is a good way to handle the situation. >> >> =A0Rainer >> =A0_______________________________________________ >> =A0OPSAWG mailing list >> =A0OPSAWG@ietf.org >> =A0https://www.ietf.org/mailman/listinfo/opsawg >> > From mbj@tail-f.com Wed Feb 25 01:05: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 882513A6841 for ; Wed, 25 Feb 2009 01:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-1.255, BAYES_00=-2.599, FRT_POSSIBLE=2.697, 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 LGD99ZmhNRo6 for ; Wed, 25 Feb 2009 01:05:19 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3BFC13A6911 for ; Wed, 25 Feb 2009 01:05:19 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E985D76C4D7; Wed, 25 Feb 2009 10:05:37 +0100 (CET) Date: Wed, 25 Feb 2009 10:05:37 +0100 (CET) Message-Id: <20090225.100537.248875324.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090224160512.GA26471@elstar.iuhb02.iu-bremen.de> References: <20090224123331.GB26046@elstar.iuhb02.iu-bremen.de> <20090224.152715.44247666.mbj@tail-f.com> <20090224160512.GA26471@elstar.iuhb02.iu-bremen.de> 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] comments on draft-ietf-opsawg-syslog-snmp-00 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, 25 Feb 2009 09:05:20 -0000 Juergen Schoenwaelder wrote: > On Tue, Feb 24, 2009 at 03:27:15PM +0100, Martin Bjorklund wrote: > > > Right. From the draft I understood that the 3584 transformation is > > supposed to be done, but now you write that it might not be possible > > to do the conversion. So what happens when the snmp-to-syslog > > translator receives a v1/v2c trap? > > I think you are confusing two things and we probably have not done a > good job explaining things well: > > (1) There is the translation of the SNMPv1 trap PDU into RFC 3416 PDU > formats. This translation is always posssible and does not > require any additional information. So a pointer to RFC 3584 > solves this issue. > > (2) There is the context information that does not exist in > SNMPv1/SNMPv2c message formats. While RFC 3584 provides a MIB > module that can do this translation, someone has to configure the > relevant tables. Since this is not realistic to assume in all > translator deployments, we made the context objects optional. > > Does this make sense now? I think the problem is the text: In general, we assume that notifications from an SNMP version preceding SNMPv3 are mapped into the notification format used ^^^^^^^^^^^^^^^^^^^^^^^^ by SNMPv3 according to the coexistance rules defined in RFC 3584 So it seems to me that you require a v2 notification to be converted into "the notification format used by v3". Anyway, it seems we agree that this text should be clarified. > > My question is if it will be useful to deploy a translator that > > translates into a "binary" form that a human user cannot understand > > without a tool that has all MIBs. > > Well, much less binary than BER encoded stuff. ;-) My point is that > for some notifications, a generic translator can't do much more than > producing hex strings. I absolutely agree. > > No. I just wonder if it would make sense to drop the other parameter > > (in the case above drop 'd'), if 'a' is provided. > > > > > I like to have a basic format I can rely on being there all > > > the time. > > > > There is already a choice in the grammar for VARVALUE; 'a' could be > > another choice there. I.e. even in the format in the draft there is > > no single VARVALUE always present. > > This could probably work but needs to be worked out in more detail. > So your proposal is to distinguish between rendered strings and > enumerations by adding more choices to the enumeration? Or do you > think it does not matter to distinguish between the string value "up" > and the enum value "up"? Or do you want to keep d= and a= for enums > but drop the hexadecimal string only for OCTET STRINGS that have an a= > representation? I must admit that I have not worked out a complete proposal for this - my first idea was just that the value could be easier to read by saying that *if* the translator has MIB knowledge then it MAY send "human readable" strings as utf8, instead of hex. Then you suggested that the same could be done for enums and bits, which I think makese sense as well. > > Again, I wonder about the deployment scenario. If all the detailed > > information is important, don't you typically have a proper SNMP > > notification receiver? Isn't one reason for existing snmp->syslog > > translators that the notification gets "readable"? > > Perhaps we need to agree on some principles: > > (i) A translator should not loose information and must no make > information carried in a notification message ambiguous. > > (ii) MIB knowledge is not required by a translator. > > (iii) A translator with MIB knowledge may generate an improved human > readable format as long as (i) and (ii) are met. > > Do we agree on this? This seems very natural. > > > And what is asdf.42 anyway? > > > > I'm sure there are notifications with objects names like this, but to > > be fair - most objects do have better names than this. > > My point was that a label is not a unique identifier and this is why I > so far insisted that the OID is always kept and VARLABEL is optionally > added for improved human readability. Yes, I agree that this follows from (i) above. I think the document needs to describe the intended usage of VARLABEL though. > Now for OCTET STRINGS where the translator knows about DISPLAY-HINT > rules, I think we can add a special case so that hexadecial > representation of the value can be skipped (assuming that the tag of > the new string representation indicates that the underlying > representation really was on OCTET STRING). Yes. > So then the question remains what we do about enumerations and bits or > OBJECT IDENTIFIER constants. One option could be to include add parameters 'E', 'B', 'O' which would be the textual representation of enums, bits, and OBJECT IDENTIFIER. In the case of the OBJECT IDENTIFIER value, I guess it has to be on the format ., or that the parameter 'o' is also needed (i.e. that 'O' is just a complement to 'o'). /martin From j.schoenwaelder@jacobs-university.de Wed Feb 25 02:39:12 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 F139428C0D0 for ; Wed, 25 Feb 2009 02:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 ad0zDZgAK39s for ; Wed, 25 Feb 2009 02:39:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9EA6E3A6A13 for ; Wed, 25 Feb 2009 02:39:10 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 489F9C000C; Wed, 25 Feb 2009 11:39:30 +0100 (CET) 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 qLyqhbOli33a; Wed, 25 Feb 2009 11:39:24 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CB4BC0010; Wed, 25 Feb 2009 11:39:24 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 51E7C9AE43F; Wed, 25 Feb 2009 11:39:23 +0100 (CET) Date: Wed, 25 Feb 2009 11:39:23 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090225103923.GB27716@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , opsawg@ietf.org References: <20090219115857.GC12569@elstar.iuhb02.iu-bremen.de> <20090223072526.GA23980@elstar.iuhb02.iu-bremen.de> 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] syslogMsgNotification, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 10:39:12 -0000 On Wed, Feb 25, 2009 at 01:09:34PM +0800, WashamFan wrote: > Yes I can start syslogMsgSDParamIndex with 0, but I have no idea > what values of 'syslogMsgSDElementName' and 'syslogMsgSDParamName' > are. If I initiate a request like: > GetNextRequest ( syslogMsgSDParamValue.X.0) > Could it return like: > Response ( syslogMsgSDParamValue.X.0."some"."thing"="value" ) It will return something like: Response ( syslogMsgSDParamValue.X.1."some"."thing"="value" ) Note that 0 is not a legal value for syslogMsgSDParamIndex but you can happily send it in a request. This is one of the features of SNMP: you can construct arbitrary OIDs and the agent returns the next accessible instance in lexicograhic order. This allows us to ask questions with incomplete instance identifiers. /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 Wed Feb 25 02:50:06 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 5E66E3A6B65 for ; Wed, 25 Feb 2009 02:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_SAVELE=2.3] 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 Ol1K76ajDdbK for ; Wed, 25 Feb 2009 02:50:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D995F3A69C5 for ; Wed, 25 Feb 2009 02:50:04 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADD93C0013; Wed, 25 Feb 2009 11:50:24 +0100 (CET) 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 7JgW9YohlYjG; Wed, 25 Feb 2009 11:50:18 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1F26C0017; Wed, 25 Feb 2009 11:50:18 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id A5BB69AE496; Wed, 25 Feb 2009 11:50:17 +0100 (CET) Date: Wed, 25 Feb 2009 11:50:17 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Message-ID: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Rainer Gerhards , opsawg@ietf.org References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> 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] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 10:50:06 -0000 On Wed, Feb 25, 2009 at 09:58:54AM +0100, Rainer Gerhards wrote: > On Wed, Feb 25, 2009 at 4:52 AM, WashamFan > wrote: > > Hi, > > > > The new indexing schema make sure 1:1 mapping between > > syslog SD parameters and SDTable entries. When reconstructing > > syslog SDEs from SDTable entries, no infomation is lost. > > Take a look at snmp SDE which is defined in syslog-snmp-00, > > interpretation of this SDE heavily depends on the order of > > SD parameters. > > Yes, and this is why I commented. In theory, a syslog relay may > reorder elements. I do not expect any such implementation in practice > (other than those I pointed out), but still one could argue that it is > valid to do so. I understand now the following: a) The SYSLOG -> SNMP mapping is fine since it preserves the SD-PARAM and the SD-ID order, even though this is not strictly required by SYSLOG. b) The SNMP -> SYSLOG mapping was written under the assumption that SYSLOG maintains the SD-PARAM order within the "snmp" SD-ID. It is now somewhat unclear to me whether it is valid to make this assumption. If we can't make this assumption, we would have to encode the varbind positions in the param names: [snmp ctxEngine="800002b804616263" ctxName="ctx1" v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860" v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0" o2="1.3.6.1.6.3.1.1.5.4" v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" v5="1.3.6.1.2.1.2.2.1.8.3" d5="1"] Is this the right approach? /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 Wed Feb 25 03:25: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 7B0BD28C155 for ; Wed, 25 Feb 2009 03:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.142, 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 S3o5eqYULpmx for ; Wed, 25 Feb 2009 03:25:41 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3635028C154 for ; Wed, 25 Feb 2009 03:25:40 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBB43C0018; Wed, 25 Feb 2009 12:25:59 +0100 (CET) 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 o7CRi1UDCEVt; Wed, 25 Feb 2009 12:25:53 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7009C0009; Wed, 25 Feb 2009 12:25:53 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id AE2A49AE58B; Wed, 25 Feb 2009 12:25:52 +0100 (CET) Date: Wed, 25 Feb 2009 12:25:52 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090225112552.GD27716@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , opsawg@ietf.org References: <20090224123331.GB26046@elstar.iuhb02.iu-bremen.de> <20090224.152715.44247666.mbj@tail-f.com> <20090224160512.GA26471@elstar.iuhb02.iu-bremen.de> <20090225.100537.248875324.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090225.100537.248875324.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:25:42 -0000 On Wed, Feb 25, 2009 at 10:05:37AM +0100, Martin Bjorklund wrote: > I think the problem is the text: > > In general, we assume that notifications from an SNMP > version preceding SNMPv3 are mapped into the notification format used > ^^^^^^^^^^^^^^^^^^^^^^^^ > by SNMPv3 according to the coexistance rules defined in RFC 3584 > > So it seems to me that you require a v2 notification to be converted > into "the notification format used by v3". Anyway, it seems we agree > that this text should be clarified. Here is the proposed new text: In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID and the contextName parameters are not present in notification messages. This document assumes that notifications are in the format defined in RFC 3416 [RFC3416]. Notifications in the SNMPv1 notification format must be translated as described in Section 3.1 of RFC 3584 [RFC3584]. > Yes, I agree that this follows from (i) above. I think the document > needs to describe the intended usage of VARLABEL though. Yes. I will add text. > > Now for OCTET STRINGS where the translator knows about DISPLAY-HINT > > rules, I think we can add a special case so that hexadecial > > representation of the value can be skipped (assuming that the tag of > > the new string representation indicates that the underlying > > representation really was on OCTET STRING). > > Yes. I just typed "I will do this" when I figured out that there is still a potential problem. A MIB aware translator able to apply DISPLAY-HINTs will turn a MacAddress binary value '00E0812E961E'h into "00:E0:81:2E:96:1E" and a MIB unaware receiver might turn this back into '30303A45303A38313A32453A39363A3145'h. This would be bad. I see two options: a) We always ship the hex value in addition to the rendered value. We might consider using base64 instead of hex to save space. b) We restrict the alternate textual representations to DISPLAY-HINTs of the form 'Na' or 'Nt' where N is some number. This implies that a MacAddress or a DateAndTime value will be carried in hex / base64 representation. Hm, not nice. > > So then the question remains what we do about enumerations and bits or > > OBJECT IDENTIFIER constants. > > One option could be to include add parameters 'E', 'B', 'O' which > would be the textual representation of enums, bits, and OBJECT > IDENTIFIER. In the case of the OBJECT IDENTIFIER value, I guess it > has to be on the format ., or that the parameter 'o' is > also needed (i.e. that 'O' is just a complement to 'o'). Since we can't expect that the receiver has MIB knowledge to turn a label such as "up" back to a number (and formally, the receiver would have to have the same version of the MIB module), I think we have to send the original value in the case of enumerations / BITS / OBJECT IDENTIFIER values and the alternate format is an optional representation. Given this, the simplest solution for the string mapping problem mentioned above would be to actually do the same. /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 Wed Feb 25 04:37:06 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 7852A28C169 for ; Wed, 25 Feb 2009 04:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.233, 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 jisE3opotvar for ; Wed, 25 Feb 2009 04:37:05 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A08DE28C0E7 for ; Wed, 25 Feb 2009 04:37:05 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 837EE76C225; Wed, 25 Feb 2009 13:37:24 +0100 (CET) Date: Wed, 25 Feb 2009 13:37:24 +0100 (CET) Message-Id: <20090225.133724.11667207.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090225112552.GD27716@elstar.iuhb02.iu-bremen.de> References: <20090224160512.GA26471@elstar.iuhb02.iu-bremen.de> <20090225.100537.248875324.mbj@tail-f.com> <20090225112552.GD27716@elstar.iuhb02.iu-bremen.de> 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] comments on draft-ietf-opsawg-syslog-snmp-00 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, 25 Feb 2009 12:37:06 -0000 Juergen Schoenwaelder wrote: > > > Now for OCTET STRINGS where the translator knows about DISPLAY-HINT > > > rules, I think we can add a special case so that hexadecial > > > representation of the value can be skipped (assuming that the tag of > > > the new string representation indicates that the underlying > > > representation really was on OCTET STRING). > > > > Yes. > > I just typed "I will do this" when I figured out that there is still a > potential problem. A MIB aware translator able to apply DISPLAY-HINTs > will turn a MacAddress binary value '00E0812E961E'h into > "00:E0:81:2E:96:1E" and a MIB unaware receiver might turn this back > into '30303A45303A38313A32453A39363A3145'h. This would be bad. I see > two options: > > a) We always ship the hex value in addition to the rendered value. We > might consider using base64 instead of hex to save space. > > b) We restrict the alternate textual representations to DISPLAY-HINTs > of the form 'Na' or 'Nt' where N is some number. This implies that > a MacAddress or a DateAndTime value will be carried in hex / base64 > representation. > > Hm, not nice. [...] > Given this, the simplest solution for the string > mapping problem mentioned above would be to actually do the same. Yes. An alternative could be that for the DISPLAY-HINTs in case b) above, the hex string does not need to be sent. /martin From rgerhards@gmail.com Wed Feb 25 04: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 AEA403A6900 for ; Wed, 25 Feb 2009 04:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SAVELE=2.3] 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 8seDpi5pkUZE for ; Wed, 25 Feb 2009 04:53:47 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id ADC633A688A for ; Wed, 25 Feb 2009 04:53:43 -0800 (PST) Received: by bwz5 with SMTP id 5so13530bwz.13 for ; Wed, 25 Feb 2009 04:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JjcXLWL/8Rdh8zCnBE50dMDhm8mDFHB37mae7HFOB94=; b=NWWZmdozO5GjJYyxjtNkSsyYbfh4FwJ62Tp4rK31Be2y/2R8got7baLlGv2rw1r9kE jWOyLURhrgWFs037Fxdwy2m1IJ1CHEzBhSDWm2B6wbrOdO7r1Zq4J2Tefgh03uI7C5p9 pg0R5ijDaszxVkJ5/GtEvJsSqvpa3a8qr6uv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ephGAT1hROPOdo1WoSWaCo9gDrGk5Mo+mM+yrUzmioQGgv2SmxboZxCpHtctBApH2m wd8eJNecIUP//YSIWdLjB++hPlq2KDrdP4ttD+OxRheE6W728pl+DX5REOztlWXqM+ea EYK1fpAAVPIo+2wKqVjOUDCuHADdkf7wuKhPk= MIME-Version: 1.0 Received: by 10.181.58.9 with SMTP id l9mr33652bkk.46.1235566442154; Wed, 25 Feb 2009 04:54:02 -0800 (PST) In-Reply-To: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> Date: Wed, 25 Feb 2009 13:54:02 +0100 Message-ID: From: Rainer Gerhards To: j.schoenwaelder@jacobs-university.de, Rainer Gerhards , opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 25 Feb 2009 12:53:48 -0000 On Wed, Feb 25, 2009 at 11:50 AM, Juergen Schoenwaelder wrote: > On Wed, Feb 25, 2009 at 09:58:54AM +0100, Rainer Gerhards wrote: >> On Wed, Feb 25, 2009 at 4:52 AM, WashamFan >> wrote: >> > Hi, >> > >> > The new indexing schema make sure 1:1 mapping between >> > syslog SD parameters and SDTable entries. When reconstructing >> > syslog SDEs from SDTable entries, no infomation is lost. >> > Take a look at snmp SDE which is defined in syslog-snmp-00, >> > interpretation of this SDE heavily depends on the order of >> > SD parameters. >> >> Yes, and this is why I commented. In theory, a syslog relay may >> reorder elements. I do not expect any such implementation in practice >> (other than those I pointed out), but still one could argue that it is >> valid to do so. > > I understand now the following: > > a) The SYSLOG -> SNMP mapping is fine since it preserves the SD-PARAM > =A0 and the SD-ID order, even though this is not strictly required by > =A0 SYSLOG. yes > b) The SNMP -> SYSLOG mapping was written under the assumption that > =A0 SYSLOG maintains the SD-PARAM order within the "snmp" SD-ID. > > =A0 It is now somewhat unclear to me whether it is valid to make this > =A0 assumption. =A0If we can't make this assumption, we would have to > =A0 encode the varbind positions in the param names: > > =A0 [snmp ctxEngine=3D"800002b804616263" ctxName=3D"ctx1" > =A0 =A0 v1=3D"1.3.6.1.2.1.1.3.0" l1=3D"sysUpTime.0" d1=3D"94860" > =A0 =A0 v2=3D"1.3.6.1.6.3.1.1.4.1.0" l2=3D"snmpTrapOID.0" o2=3D"1.3.6.1.6= .3.1.1.5.4" > =A0 =A0 v3=3D"1.3.6.1.2.1.2.2.1.1.3" d3=3D"3" > =A0 =A0 v4=3D"1.3.6.1.2.1.2.2.1.7.3" d4=3D"1" > =A0 =A0 v5=3D"1.3.6.1.2.1.2.2.1.8.3" d5=3D"1"] > > =A0 Is this the right approach? Yes, that would work in all cases and without any doubt. However, as unfortunately often in syslog, we need to weigh what is the least worse approach: That binding will always work, but it requires some more space (which is a scarce resource in syslog). Without the sequence identifiers, there is a slight chance that SD-Params get rerodered, but we preserve the space. I am not SNMP literate enough, so can you tell me how long (roughly) you would expect a typical SNMP notification, encoded as syslog message, would be? If it is over 2K, there is a problem. In any case, I lean towards the approach with the sequence identifiers. I envision that syslog implementations will parse the SDEs into a set-like structure, with the primary navigational key being the SD-ID. Then, I'd expect that each node contains a set of param names, identified by param name and each of them contains a set of values. Note that I intentionally use the word "set" over "tupel", because I have the assumption that when traversing this structure, sequence of occurrence will not necessarily be taken into account. But obviously, the sequence will most probably exist in the in-memory representations and will lead to correct reconstruction of the sequence when a message is forwarded. All of this is not normative, but just my thought about how a syslog engine may implement structured data elements. Other implementers may have totally different (and valid) ways to approach this. Rainer From rgerhards@gmail.com Wed Feb 25 04:57:46 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 C0D503A6AA4 for ; Wed, 25 Feb 2009 04:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, MANGLED_SAVELE=2.3] 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 6hKb-i78vFoi for ; Wed, 25 Feb 2009 04:57:46 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 7C4EB3A688A for ; Wed, 25 Feb 2009 04:57:45 -0800 (PST) Received: by fxm11 with SMTP id 11so3767102fxm.13 for ; Wed, 25 Feb 2009 04:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=oD6XvR1be8z0SKXb8jB0YvUJP4c8uocujdrubmMuzu4=; b=Rjdvh04Lj8N0GizBW10oRpb7BwVv3NMjJztZi6amvXQ5KVVNqNsI/ITZXkCfufvnL5 iQVA0EdF4teH2ZSZLGDRB/X7adj1ydBwlHA+1QMHHDdWj4XDgndDHUPUO+Jp8pueczEH aCIpa35Hs5Csy8Z6IEwNf8Wpk65ZW2rpJM5f0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=SQwKlxyhY5p67xMi48BUmqAvv3jXiJlbLaPjn2rehI1zNNeo7u4Jm8DecOYM+HtipX awF7Fee/3DRhHwKnziuG9nfUY/Jsmz9R3NIq601WhcLWa0xBCybKc/lyrfHNnbLA9UGZ J319ui3Q+1SZEbXods9nTKUaf1pJAFZ6KTV0Y= MIME-Version: 1.0 Received: by 10.181.36.9 with SMTP id o9mr27247bkj.148.1235566683585; Wed, 25 Feb 2009 04:58:03 -0800 (PST) In-Reply-To: References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> Date: Wed, 25 Feb 2009 13:58:03 +0100 Message-ID: From: Rainer Gerhards To: j.schoenwaelder@jacobs-university.de, Rainer Gerhards , opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 25 Feb 2009 12:57:46 -0000 I forgot to mention that all syslog engines are cautioned against changing the message content (a recommendation inside the normative text), so I would assume that order of SD-PARAMS is almost never changed. The big motivator behind this was syslog-sign. The syslog WG did not mandate it, though, as a number of exotic use cases popped up where modification of SDEs would have benefit and may be preferred over keeping everything as is - even if that means problems with e.g. signatures. The primary use case, as written yesterday, were relays recording path information inside the message. Rainer On Wed, Feb 25, 2009 at 1:54 PM, Rainer Gerhards wrot= e: > On Wed, Feb 25, 2009 at 11:50 AM, Juergen Schoenwaelder > wrote: >> On Wed, Feb 25, 2009 at 09:58:54AM +0100, Rainer Gerhards wrote: >>> On Wed, Feb 25, 2009 at 4:52 AM, WashamFan >>> wrote: >>> > Hi, >>> > >>> > The new indexing schema make sure 1:1 mapping between >>> > syslog SD parameters and SDTable entries. When reconstructing >>> > syslog SDEs from SDTable entries, no infomation is lost. >>> > Take a look at snmp SDE which is defined in syslog-snmp-00, >>> > interpretation of this SDE heavily depends on the order of >>> > SD parameters. >>> >>> Yes, and this is why I commented. In theory, a syslog relay may >>> reorder elements. I do not expect any such implementation in practice >>> (other than those I pointed out), but still one could argue that it is >>> valid to do so. >> >> I understand now the following: >> >> a) The SYSLOG -> SNMP mapping is fine since it preserves the SD-PARAM >> =A0 and the SD-ID order, even though this is not strictly required by >> =A0 SYSLOG. > > yes > >> b) The SNMP -> SYSLOG mapping was written under the assumption that >> =A0 SYSLOG maintains the SD-PARAM order within the "snmp" SD-ID. >> >> =A0 It is now somewhat unclear to me whether it is valid to make this >> =A0 assumption. =A0If we can't make this assumption, we would have to >> =A0 encode the varbind positions in the param names: >> >> =A0 [snmp ctxEngine=3D"800002b804616263" ctxName=3D"ctx1" >> =A0 =A0 v1=3D"1.3.6.1.2.1.1.3.0" l1=3D"sysUpTime.0" d1=3D"94860" >> =A0 =A0 v2=3D"1.3.6.1.6.3.1.1.4.1.0" l2=3D"snmpTrapOID.0" o2=3D"1.3.6.1.= 6.3.1.1.5.4" >> =A0 =A0 v3=3D"1.3.6.1.2.1.2.2.1.1.3" d3=3D"3" >> =A0 =A0 v4=3D"1.3.6.1.2.1.2.2.1.7.3" d4=3D"1" >> =A0 =A0 v5=3D"1.3.6.1.2.1.2.2.1.8.3" d5=3D"1"] >> >> =A0 Is this the right approach? > > Yes, that would work in all cases and without any doubt. However, as > unfortunately often in syslog, we need to weigh what is the least > worse approach: That binding will always work, but it requires some > more space (which is a scarce resource in syslog). Without the > sequence identifiers, there is a slight chance that SD-Params get > rerodered, but we preserve the space. > > I am not SNMP literate enough, so can you tell me how long (roughly) > you would expect a typical SNMP notification, encoded as syslog > message, would be? If it is over 2K, there is a problem. > > In any case, I lean towards the approach with the sequence > identifiers. I envision that syslog implementations will parse the > SDEs into a set-like structure, with the primary navigational key > being the SD-ID. Then, I'd expect that each node contains a set of > param names, identified by param name and each of them contains a set > of values. Note that I intentionally use the word "set" over "tupel", > because I have the assumption that when traversing this structure, > sequence of occurrence will not necessarily be taken into account. But > obviously, the sequence will most probably exist in the in-memory > representations and will lead to correct reconstruction of the > sequence when a message is forwarded. =A0All of this is not normative, > but just my thought about how a syslog engine may implement structured > data elements. Other implementers may have totally different (and > valid) ways to approach this. > > Rainer > From mbj@tail-f.com Wed Feb 25 05:11: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 669C928C169 for ; Wed, 25 Feb 2009 05:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.209, 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 XPwwJ7veyvCk for ; Wed, 25 Feb 2009 05:11:37 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9C8C43A680B for ; Wed, 25 Feb 2009 05:11:37 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 360A876C225; Wed, 25 Feb 2009 14:11:57 +0100 (CET) Date: Wed, 25 Feb 2009 14:11:56 +0100 (CET) Message-Id: <20090225.141156.142569965.mbj@tail-f.com> To: rgerhards@gmail.com From: Martin Bjorklund In-Reply-To: References: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 25 Feb 2009 13:11:38 -0000 Rainer Gerhards wrote: > > =A0 [snmp ctxEngine=3D"800002b804616263" ctxName=3D"ctx1" > > =A0 =A0 v1=3D"1.3.6.1.2.1.1.3.0" l1=3D"sysUpTime.0" d1=3D"94860" > > =A0 =A0 v2=3D"1.3.6.1.6.3.1.1.4.1.0" l2=3D"snmpTrapOID.0" o2=3D"1.3= .6.1.6.3.1.1.5.4" > > =A0 =A0 v3=3D"1.3.6.1.2.1.2.2.1.1.3" d3=3D"3" > > =A0 =A0 v4=3D"1.3.6.1.2.1.2.2.1.7.3" d4=3D"1" > > =A0 =A0 v5=3D"1.3.6.1.2.1.2.2.1.8.3" d5=3D"1"] > > > > =A0 Is this the right approach? > = > Yes, that would work in all cases and without any doubt. An alternative might be to introduce another SD-ID "snmpVarbind" or "snmpVb" which enapsulates the v/l/d/... parameters. It would also need an index parameter: [snmp ctxEngine=3D"800002b804616263" ctxName=3D"ctx1"] [snmpVb i=3D"1" v=3D"1.3.6.1.2.1.1.3.0" l=3D"sysUpTime.0" d=3D"94860= "] [snmpVb i=3D"2" v=3D"1.3.6.1.6.3.1.1.4.1.0" l=3D"snmpTrapOID.0" o=3D"1.3.6.1.6.3.1.1.5.4"] [snmpVb i=3D"3" v=3D"1.3.6.1.2.1.2.2.1.1.3" d=3D"3"] [snmpVb i=3D"4" v=3D"1.3.6.1.2.1.2.2.1.7.3" d=3D"1"] [snmpVb i=3D"5" v=3D"1.3.6.1.2.1.2.2.1.8.3" d=3D"1"] /martin From j.schoenwaelder@jacobs-university.de Wed Feb 25 07:53:33 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 A23303A695E for ; Wed, 25 Feb 2009 07:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.137, 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 R8vXuCCUEwcH for ; Wed, 25 Feb 2009 07:53:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 757F73A68A9 for ; Wed, 25 Feb 2009 07:53:32 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82DAFC0004; Wed, 25 Feb 2009 16:53:52 +0100 (CET) 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 AvHs4O3LMGzC; Wed, 25 Feb 2009 16:53:46 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C1BBC000E; Wed, 25 Feb 2009 16:53:46 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 446D49AEF5D; Wed, 25 Feb 2009 16:53:45 +0100 (CET) Date: Wed, 25 Feb 2009 16:53:45 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Message-ID: <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Rainer Gerhards , opsawg@ietf.org References: <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> 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] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:53:33 -0000 On Wed, Feb 25, 2009 at 01:58:03PM +0100, Rainer Gerhards wrote: > I forgot to mention that all syslog engines are cautioned against > changing the message content (a recommendation inside the normative > text), so I would assume that order of SD-PARAMS is almost never > changed. The big motivator behind this was syslog-sign. The syslog WG > did not mandate it, though, as a number of exotic use cases popped up > where modification of SDEs would have benefit and may be preferred > over keeping everything as is - even if that means problems with e.g. > signatures. The primary use case, as written yesterday, were relays > recording path information inside the message. For us, it is OK if someone adds SD-IDs. We only have a problem if someone rearranges the params in an SD-ID. Is it safe to assume that nobody rearranges params in SD-IDs? /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 Wed Feb 25 07:55:18 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 F21333A6A96 for ; Wed, 25 Feb 2009 07:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.133, 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 2akRWA3KmLIW for ; Wed, 25 Feb 2009 07:55:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E37113A6A87 for ; Wed, 25 Feb 2009 07:55:17 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1D4FC0009; Wed, 25 Feb 2009 16:55:37 +0100 (CET) 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 TkRLLqPgjyw9; Wed, 25 Feb 2009 16:55:32 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5FEDC0004; Wed, 25 Feb 2009 16:55:31 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id D8B729AEFA0; Wed, 25 Feb 2009 16:55:30 +0100 (CET) Date: Wed, 25 Feb 2009 16:55:30 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090225155530.GB28972@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Martin Bjorklund , rgerhards@gmail.com, opsawg@ietf.org References: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090225.141156.142569965.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090225.141156.142569965.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:55:19 -0000 On Wed, Feb 25, 2009 at 02:11:56PM +0100, Martin Bjorklund wrote: > Rainer Gerhards wrote: > > > ? [snmp ctxEngine="800002b804616263" ctxName="ctx1" > > > ? ? v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860" > > > ? ? v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0" o2="1.3.6.1.6.3.1.1.5.4" > > > ? ? v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" > > > ? ? v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" > > > ? ? v5="1.3.6.1.2.1.2.2.1.8.3" d5="1"] > > > > > > ? Is this the right approach? > > > > Yes, that would work in all cases and without any doubt. > > An alternative might be to introduce another SD-ID "snmpVarbind" or > "snmpVb" which enapsulates the v/l/d/... parameters. It would also > need an index parameter: > > [snmp ctxEngine="800002b804616263" ctxName="ctx1"] > [snmpVb i="1" v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860"] > [snmpVb i="2" v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" > o="1.3.6.1.6.3.1.1.5.4"] > [snmpVb i="3" v="1.3.6.1.2.1.2.2.1.1.3" d="3"] > [snmpVb i="4" v="1.3.6.1.2.1.2.2.1.7.3" d="1"] > [snmpVb i="5" v="1.3.6.1.2.1.2.2.1.8.3" d="1"] But the order of the snmpVb matters as well, so you have to number them and the overall saving will be close to zero if not negative. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rgerhards@gmail.com Wed Feb 25 08:02:05 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 3CF553A6AB3 for ; Wed, 25 Feb 2009 08:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 wggxTFg6LQON for ; Wed, 25 Feb 2009 08:02:04 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 0076D3A6AAF for ; Wed, 25 Feb 2009 08:02:03 -0800 (PST) Received: by bwz26 with SMTP id 26so46980bwz.37 for ; Wed, 25 Feb 2009 08:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=R5wBq8j2stegf4VvAMnhN842+CynPL9KOII0KBZsASg=; b=Yy+E5Z1Ryt+nhDJppfjK43S0F/qDup0zzXxJhodbieCdlYJ77IQK5bjk5s0RuzeW/n 5itvMC3oXU8+rvk0kcQqoLyddI8NS3diQ1du5nCNxJB3qkGZ+szch6jjGOM8Ye81ByoM wV7zsuPw1X/80VV5u63naNqgjECUZcxOnkdo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ruKbtpMr1tNLd7Blo/pQFnBUa9ZXJKOn9Gqc6tZG2Rrd0Ibl3P9CP9TpqwdqUJN05B 0t3CtvQbBY1NT9kZt2jlgxQJXhiZXg6av0Uo3RqOWMcE1Kpzt4PYCpNA+7zVMFA81Xtq WMBdWYfsDE8OGdedJqdse/X13Q7s5jAKKoekg= MIME-Version: 1.0 Received: by 10.181.36.18 with SMTP id o18mr81413bkj.136.1235577742133; Wed, 25 Feb 2009 08:02:22 -0800 (PST) In-Reply-To: <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> References: <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> Date: Wed, 25 Feb 2009 17:02:21 +0100 Message-ID: From: Rainer Gerhards To: j.schoenwaelder@jacobs-university.de, Rainer Gerhards , opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Wed, 25 Feb 2009 16:02:05 -0000 On Wed, Feb 25, 2009 at 4:53 PM, Juergen Schoenwaelder wrote: > On Wed, Feb 25, 2009 at 01:58:03PM +0100, Rainer Gerhards wrote: >> I forgot to mention that all syslog engines are cautioned against >> changing the message content (a recommendation inside the normative >> text), so I would assume that order of SD-PARAMS is almost never >> changed. The big motivator behind this was syslog-sign. The syslog WG >> did not mandate it, though, as a number of exotic use cases popped up >> where modification of SDEs would have benefit and may be preferred >> over keeping everything as is - even if that means problems with e.g. >> signatures. The primary use case, as written yesterday, were relays >> recording path information inside the message. > > For us, it is OK if someone adds SD-IDs. We only have a problem if > someone rearranges the params in an SD-ID. Is it safe to assume that > nobody rearranges params in SD-IDs? Hard to say. Let me phrase it that way: it is not forbidden. So I can't outrule someone at some time will do... In my personal view, it is highly unlikely, though. Adding sequence identifiers will work in all cases, but I do not know if the extra space required may cause problems (as I do not know the anticipated average message sizes). Rainer From j.schoenwaelder@jacobs-university.de Wed Feb 25 09:05: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 000A128C258 for ; Wed, 25 Feb 2009 09:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 G4RIDwdx37M6 for ; Wed, 25 Feb 2009 09:05:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B726928C232 for ; Wed, 25 Feb 2009 09:05:35 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8758C000E; Wed, 25 Feb 2009 18:05:55 +0100 (CET) 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 hsnGMx5WjkMK; Wed, 25 Feb 2009 18:05:49 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51CCCC0006; Wed, 25 Feb 2009 18:05:49 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 3CE409AF108; Wed, 25 Feb 2009 18:05:48 +0100 (CET) Date: Wed, 25 Feb 2009 18:05:48 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Message-ID: <20090225170548.GA29067@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Rainer Gerhards , opsawg@ietf.org References: <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> 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] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:05:37 -0000 On Wed, Feb 25, 2009 at 05:02:21PM +0100, Rainer Gerhards wrote: > On Wed, Feb 25, 2009 at 4:53 PM, Juergen Schoenwaelder > wrote: > > On Wed, Feb 25, 2009 at 01:58:03PM +0100, Rainer Gerhards wrote: > >> I forgot to mention that all syslog engines are cautioned against > >> changing the message content (a recommendation inside the normative > >> text), so I would assume that order of SD-PARAMS is almost never > >> changed. The big motivator behind this was syslog-sign. The syslog WG > >> did not mandate it, though, as a number of exotic use cases popped up > >> where modification of SDEs would have benefit and may be preferred > >> over keeping everything as is - even if that means problems with e.g. > >> signatures. The primary use case, as written yesterday, were relays > >> recording path information inside the message. > > > > For us, it is OK if someone adds SD-IDs. We only have a problem if > > someone rearranges the params in an SD-ID. Is it safe to assume that > > nobody rearranges params in SD-IDs? > > Hard to say. Let me phrase it that way: it is not forbidden. So I > can't outrule someone at some time will do... In my personal view, it > is highly unlikely, though. Adding sequence identifiers will work in > all cases, but I do not know if the extra space required may cause > problems (as I do not know the anticipated average message sizes). Well, the sequence number usually adds two bytes per SNMP varbind. If we want to save space, we can invent more compact OID notations (e.g. compressing well known prefixes) or we can move from hex encoding to base64 encoding of binary values. I can try to dig out common notification sizes form some studies we did several years ago or with some more effort we could check the SNMP traces we collected from operational networks and recode the notifications in there. But this takes some time and effort. /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 Wed Feb 25 10:38:33 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 5C6703A68AC for ; Wed, 25 Feb 2009 10:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.109, 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 kov8rkKgA7fE for ; Wed, 25 Feb 2009 10:38:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 89C433A698D for ; Wed, 25 Feb 2009 10:38:32 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C3F7076C225; Wed, 25 Feb 2009 19:38:51 +0100 (CET) Date: Wed, 25 Feb 2009 19:38:51 +0100 (CET) Message-Id: <20090225.193851.89466600.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090225155530.GB28972@elstar.iuhb02.iu-bremen.de> References: <20090225.141156.142569965.mbj@tail-f.com> <20090225155530.GB28972@elstar.iuhb02.iu-bremen.de> 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] syslogMsgSDTable, syslog-msg-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: Wed, 25 Feb 2009 18:38:33 -0000 Juergen Schoenwaelder wrote: > On Wed, Feb 25, 2009 at 02:11:56PM +0100, Martin Bjorklund wrote: > > An alternative might be to introduce another SD-ID "snmpVarbind" or > > "snmpVb" which enapsulates the v/l/d/... parameters. It would also > > need an index parameter: > > > > [snmp ctxEngine="800002b804616263" ctxName="ctx1"] > > [snmpVb i="1" v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860"] > > [snmpVb i="2" v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" > > o="1.3.6.1.6.3.1.1.5.4"] > > [snmpVb i="3" v="1.3.6.1.2.1.2.2.1.1.3" d="3"] > > [snmpVb i="4" v="1.3.6.1.2.1.2.2.1.7.3" d="1"] > > [snmpVb i="5" v="1.3.6.1.2.1.2.2.1.8.3" d="1"] > > But the order of the snmpVb matters as well, so you have to number > them ... which I did with the 'i' parameter. > and the overall saving will be close to zero if not negative. Yes this encoding uses more bytes. The only advantage would be that it looks a bit "cleaner". /martin From ietfdbh@comcast.net Wed Feb 25 11:45:35 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 6FBE128C302 for ; Wed, 25 Feb 2009 11:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 4dWx5ypRFXm4 for ; Wed, 25 Feb 2009 11:45:34 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 2D6F928C2E2 for ; Wed, 25 Feb 2009 11:45:34 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA07.westchester.pa.mail.comcast.net with comcast id LKhT1b04s0bG4ec57KlvMu; Wed, 25 Feb 2009 19:45:55 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id LKlu1b0010UQ6dC3PKluAj; Wed, 25 Feb 2009 19:45:54 +0000 From: "David Harrington" To: , Date: Wed, 25 Feb 2009 14:45:52 -0500 Message-ID: <0b7a01c99781$ab3396b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0B7B_01C99757.C25D8EB0" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmXdyHBMKJTeTQ6QhS5QbybqFSlpQACnyZQ Subject: [OPSAWG] FW: I-D ACTION:draft-feng-syslog-transport-dtls-00.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: Wed, 25 Feb 2009 19:45:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0B7B_01C99757.C25D8EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, February 25, 2009 1:30 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-feng-syslog-transport-dtls-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of SYSLOG message over DTLS Author(s) : H. Feng Filename : draft-feng-syslog-transport-dtls-00.txt Pages : 10 Date : 2009-2-25 This document describes a Transport for the Syslog Protocol, which 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 connectionless (UDP) transport is preferred, and integrates well into existing public keying infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-feng-syslog-transport-dtls-0 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0B7B_01C99757.C25D8EB0 Content-Type: Message/External-body; name="draft-feng-syslog-transport-dtls-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-feng-syslog-transport-dtls-00.txt" Content-Type: text/plain Content-ID: <2009-2-25101745.I-D@ietf.org> ------=_NextPart_000_0B7B_01C99757.C25D8EB0 Content-Type: text/plain; name="ATT02888.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02888.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_0B7B_01C99757.C25D8EB0-- From dbharrington@comcast.net Wed Feb 25 13:36:02 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 6A0263A68BC for ; Wed, 25 Feb 2009 13:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 JGsvePGPyRxY for ; Wed, 25 Feb 2009 13:36:01 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 0E66F3A6B90 for ; Wed, 25 Feb 2009 13:36:00 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA10.westchester.pa.mail.comcast.net with comcast id LAuj1b00417dt5G5AMcNK7; Wed, 25 Feb 2009 21:36:22 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id LMcM1b00J0UQ6dC3ZMcNVC; Wed, 25 Feb 2009 21:36:22 +0000 From: "David B Harrington" To: Date: Wed, 25 Feb 2009 16:36:20 -0500 Message-ID: <0bf801c99791$19a2edd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmQMc1dGxGIJFdGSMmJxrd30VDb+QAF6MAgAdHfrEA= Subject: [OPSAWG] FW: (final) WGLC on draft-ietf-opsawg-operations-and-management 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, 25 Feb 2009 21:36:02 -0000 Hi, Adrian and I have different perspectives on what the document should say. Can you please review this thread and comment on the list so the chairs can decide what the document should say? Thanks, dbh -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Monday, February 16, 2009 10:59 AM To: 'Adrian Farrel' Subject: RE: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management Hi Adrian, I think there is some correlation between security considerations and management considerations. I think part of the motivation for this document is to make it more so. For security, you start by analyzing the security needs, and deciding which ones are relevant to your protocol. You might need to deal with authentication, confidentiality, integrity checking, replay protoction, etc. There are a reasonably standardized set of threats to consider. Sometimes, you need to make some adjustment to your protocol to address threats, but often using an existing standard protocol as-is can mitigate the threats just fine. Then you normally recommend one of the standard protocols to mitigate the threats. For interoperability purposes, it is considered important to specify a mandatory-to-implement solution, even if other solutions are acceptable as well. For management, you should start by analyzing the needs, and deciding which are relevant to your protocol. Needs often include notifications for fault or threshold conditions, logging, configuration, performance monitoring, usage accounting, and security of the management messages and management datastores. By documenting these common needs here, we hope to "standardize" them more than they are now. (and this discussion with you might help me immensely figure out how to reorganize the document to "tell a story" better). A protocol may need be adjusted to address the management needs, such as specifying th eneed to maintain counters, and identifying which events should be counted. Then, I think it would be very appropriate to show how one of the standard protocols can be used to address these needs in an interoperable manner. The IEEE uses this model - it defines an information model, and then shows how one protocol (GDMO or a MIB) can represent the information. This document is not trying to dictate what protocol should be used, nor is it recommending that the suggested management protocol be mandatory. The IESG can decide whether they want to start requiring mandatory-to-implement management, similar to BCP61. As far as I am concerned, if the IESG wants to mandate "strong management" for IETF protocols, that should be a different document than this discussion of common "threats". dbh > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Monday, February 16, 2009 7:25 AM > To: David B Harrington > Subject: Re: [OPSAWG] (final) WGLC on > draft-ietf-opsawg-operations-and-management > > Hi David, > > > would this be better? > > OLD: > > This document suggests protocol designers consider operations and > > management needs and then recommend appropriate standard > management > > protocols and data models to address the relevant operations and > > management needs. This is similar to a WG considering which > > security threats are relevant to their protocol, and then > recommending > > appropriate standard security protocols to mitigate the relevant > > threats. > > NEW: > > Protocol designers should consider operations and management needs, > > document how to meet those needs, and suggest standard management > > protocols and data models that could meet the operations and > > management needs. This is similar to a working group (WG) that > > considers which security threats are relevant to their protocol, > > documents how threats should be mitigated, and then suggests > > appropriate standard protocols that could mitigate the threats. > > Thanks for engaging... > > My main issue is that it is not germane to the specification > of one protocol > which other protocol is used for management interactions with > devices that > implement the specified protocol. > > For example, OSPF is widely implemented. It seems to me that > if the OSPF > specification had said that "OSPF implementations MUST/SHOULD be > configurable using TL1" we would have achieved one of two results: > 1. OSPF would not have bee successfully or widely deployed. > 2. Most people would have ignored the specification. > > We don't want to arrive at either of these situation for new > protocols. > > I understand that you want to arrive at interoperability of > management > systems, but I don't think it works like that! For example, we do not > require that all routers support PIM. We say that there is a bunch of > routing protocols, and people can implement what they want. > We do specify > that a network that runs OSPF must be made up of OSPF-capable > routers, and > we specify how those routers interoperate when they run OSPF. > > Which routing protocols a device supports is a commercial decision. > Purchasers decide which protocols they want to deploy, and > buy equipment > accordingly. If they want OSPF and PIM, they do not buy > devices that support > only IS-IS and PIM, or only OSPF and BGP. > > Surely the same applies for management protocols? > > I also really think that this is not like the security > considerations. > Security techniques are imbedded into the protocol being designed. > Management is an adjunct (no matter how important). > > How about... > > Protocol designers should consider operations and management > needs, document > how to meet those needs, and define a data model for the > configuration and > management of the protocol. Protocol designers may also > suggest the use of > one or more standard management protocols as a core subset of > management > access techniques for implementations of the protocol being designed. > > Adrian > > From Washam.Fan@huaweisymantec.com Wed Feb 25 18:16:10 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 6063328C2CF for ; Wed, 25 Feb 2009 18:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 5PhxkaWA4+U8 for ; Wed, 25 Feb 2009 18:16:09 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 596CD28C2CB for ; Wed, 25 Feb 2009 18:16:09 -0800 (PST) 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 <0KFN005FSIBDFS20@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 10:16:27 +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 <0KFN00CARIBB1B20@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 10:16:25 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 26 Feb 2009 10:16:23 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 26 Feb 2009 10:16:23 +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: <20090225.141156.142569965.mbj@tail-f.com> References: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090225.141156.142569965.mbj@tail-f.com> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 26 Feb 2009 02:16:10 -0000 Hi, > An alternative might be to introduce another SD-ID "snmpVarbind" or > "snmpVb" which enapsulates the v/l/d/... parameters. It would also > need an index parameter: > > [snmp ctxEngine="800002b804616263" ctxName="ctx1"] > [snmpVb i="1" v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860"] > [snmpVb i="2" v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" > o="1.3.6.1.6.3.1.1.5.4"] > [snmpVb i="3" v="1.3.6.1.2.1.2.2.1.1.3" d="3"] > [snmpVb i="4" v="1.3.6.1.2.1.2.2.1.7.3" d="1"] > [snmpVb i="5" v="1.3.6.1.2.1.2.2.1.8.3" d="1"] I am afraid this approach is even not allowed. Check the 1st para, sec 6.3.2, syslog-protocol-23: SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. The same SD-ID MUST NOT exist more than once in a message. washam From Washam.Fan@huaweisymantec.com Wed Feb 25 19:25: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 ED8BC3A6813 for ; Wed, 25 Feb 2009 19:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, MANGLED_SAVELE=2.3] 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 5+xhvrX4PWUo for ; Wed, 25 Feb 2009 19:25:29 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 0F2743A6844 for ; Wed, 25 Feb 2009 19:25:29 -0800 (PST) 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 <0KFN0053HLIWFS30@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 11:25: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 <0KFN00GIALIUTP00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 11:25:44 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 26 Feb 2009 11:25:42 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 26 Feb 2009 11:25: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: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> References: <20090218075024.GA8037@elstar.iuhb02.iu-bremen.de> <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 26 Feb 2009 03:25:30 -0000 Hi, > I understand now the following: > > a) The SYSLOG -> SNMP mapping is fine since it preserves the SD-PARAM > and the SD-ID order, even though this is not strictly required by > SYSLOG. > > b) The SNMP -> SYSLOG mapping was written under the assumption that > SYSLOG maintains the SD-PARAM order within the "snmp" SD-ID. > > It is now somewhat unclear to me whether it is valid to make this > assumption. If we can't make this assumption, we would have to > encode the varbind positions in the param names: > > [snmp ctxEngine="800002b804616263" ctxName="ctx1" > v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860" > v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0" o2="1.3.6.1.6.3.1.1.5.4" > v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" > v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" > v5="1.3.6.1.2.1.2.2.1.8.3" d5="1"] > > Is this the right approach? How many parameters do you like to define? v1-v100, d1-d100,...? It seems to me not a conventional way to define a SDE. But I can't come up with a better way to do order issue;) washam From Washam.Fan@huaweisymantec.com Wed Feb 25 19:32:12 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 C16BE3A6BCE for ; Wed, 25 Feb 2009 19:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.462, 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 d9xNN21OZvjH for ; Wed, 25 Feb 2009 19:32:12 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id BA61C3A6BCC for ; Wed, 25 Feb 2009 19:32:11 -0800 (PST) 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 <0KFN00CUULU6QC30@hstga01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 11:32:30 +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 <0KFN00GJCLU6TP00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 11:32:30 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 26 Feb 2009 11:32:30 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 26 Feb 2009 11:32:30 +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: <20090225170548.GA29067@elstar.iuhb02.iu-bremen.de> References: <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> <20090225170548.GA29067@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 26 Feb 2009 03:32:12 -0000 > On Wed, Feb 25, 2009 at 05:02:21PM +0100, Rainer Gerhards wrote: > > On Wed, Feb 25, 2009 at 4:53 PM, Juergen Schoenwaelder > > wrote: > > > On Wed, Feb 25, 2009 at 01:58:03PM +0100, Rainer Gerhards wrote: > > >> I forgot to mention that all syslog engines are cautioned against > > >> changing the message content (a recommendation inside the normative > > >> text), so I would assume that order of SD-PARAMS is almost never > > >> changed. The big motivator behind this was syslog-sign. The > syslog WG > > >> did not mandate it, though, as a number of exotic use cases > popped up > > >> where modification of SDEs would have benefit and may be preferred > > >> over keeping everything as is - even if that means problems with > e.g. > > >> signatures. The primary use case, as written yesterday, were relays > > >> recording path information inside the message. > > > > > > For us, it is OK if someone adds SD-IDs. We only have a problem if > > > someone rearranges the params in an SD-ID. Is it safe to assume that > > > nobody rearranges params in SD-IDs? > > > > Hard to say. Let me phrase it that way: it is not forbidden. So I > > can't outrule someone at some time will do... In my personal view, > it > > is highly unlikely, though. Adding sequence identifiers will work in > > all cases, but I do not know if the extra space required may cause > > problems (as I do not know the anticipated average message sizes). > > Well, the sequence number usually adds two bytes per SNMP varbind. If > we want to save space, we can invent more compact OID notations (e.g. > compressing well known prefixes) or we can move from hex encoding to > base64 encoding of binary values. > > I can try to dig out common notification sizes form some studies we > did several years ago or with some more effort we could check the > SNMP traces we collected from operational networks and recode the > notifications in there. But this takes some time and effort. It seems more issues to be handled when we put complicated thing like SNMP upon simple thing like syslog. order issue is a thing and size truncation seems another. I think SNMP messages go through syslog tunnel may lose some information, now. washam From banshimin@h3c.com Wed Feb 25 21:36:51 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 41C053A6B8C for ; Wed, 25 Feb 2009 21:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.928 X-Spam-Level: **** X-Spam-Status: No, score=4.928 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1, RELAY_IS_221=2.222] 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 ffCIxs6ZadCI for ; Wed, 25 Feb 2009 21:36:50 -0800 (PST) Received: from huawei-3com.com (unknown [221.12.31.56]) by core3.amsl.com (Postfix) with ESMTP id 70E0C3A6B8A for ; Wed, 25 Feb 2009 21:36:48 -0800 (PST) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KFN002YYRLXIA@h3cml01-in.huawei-3com.com> for opsawg@ietf.org; Thu, 26 Feb 2009 13:37:09 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KFN0023CRLX82@h3cml01-in.huawei-3com.com> for opsawg@ietf.org; Thu, 26 Feb 2009 13:37:09 +0800 (CST) Received: from unknown (HELO b01376c) ([10.153.130.54]) by mailsecurity.h3c.com with ESMTP; Thu, 26 Feb 2009 13:43:40 +0800 Date: Thu, 26 Feb 2009 13:37:07 +0800 From: Shimin Ban To: opsawg@ietf.org Message-id: <013301c997d4$434f4820$3682990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_r2bl3uJSyCGhRQcPILHw8w)" X-Priority: 3 X-MSMail-priority: Normal Subject: [OPSAWG] I would like to extend ENTITY-MIB (rfc4133)... 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, 26 Feb 2009 05:36:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_r2bl3uJSyCGhRQcPILHw8w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hello, I would like to extend RFC4133. I'ld like to add the following information to entity MIB: (1) The absolute position of the entity in its parent According to the absolute position and the information provided by entity MIB, the NMS can display the panel of devices easily regardless of vendor. The customer could monitor the status of the entity easily through the panel. But the entity MIB does not provide the entity status information. (2) The status of the entity (3) The other important information of CPU, Sensor, disk, powersupply etc. Can the ENTITY-MIB be extended? What needs to happen? Thank you very much. Cheers Shimin Ban --Boundary_(ID_r2bl3uJSyCGhRQcPILHw8w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hello,
I would like to extend RFC4133. I'ld like to add the following information to entity MIB:
 
(1) The absolute position of the entity in its parent
According to the absolute position and the information provided by entity MIB, the NMS can display the panel of devices easily regardless of vendor.
The customer could monitor the status of the entity easily through the panel. But the entity MIB does not provide the entity status information.
(2) The status of the entity
(3) The other important information of CPU, Sensor, disk, powersupply etc.
 
Can the ENTITY-MIB be extended? What needs to happen?
Thank you very much.
 
Cheers
Shimin Ban
 
 
 
--Boundary_(ID_r2bl3uJSyCGhRQcPILHw8w)-- From j.schoenwaelder@jacobs-university.de Thu Feb 26 00:34: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 F1FF13A69A1 for ; Thu, 26 Feb 2009 00:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 4QdKaocNOd6E for ; Thu, 26 Feb 2009 00:34:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C59373A67AA for ; Thu, 26 Feb 2009 00:34:20 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A51EDC0056; Thu, 26 Feb 2009 09:34:41 +0100 (CET) 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 QdBv+HddP2nd; Thu, 26 Feb 2009 09:34:35 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35576C0016; Thu, 26 Feb 2009 09:34:35 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 31EAF9AFB9E; Thu, 26 Feb 2009 09:34:34 +0100 (CET) Date: Thu, 26 Feb 2009 09:34:34 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090226083434.GC29756@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , Rainer Gerhards , opsawg@ietf.org References: <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> 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] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 08:34:22 -0000 On Thu, Feb 26, 2009 at 11:25:42AM +0800, WashamFan wrote: > How many parameters do you like to define? v1-v100, d1-d100,...? I will define them without putting an explicit upper bound into place. /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 Thu Feb 26 00:36:13 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 12BD13A6B04 for ; Thu, 26 Feb 2009 00:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.119, 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 EpzQL+6aXERO for ; Thu, 26 Feb 2009 00:36:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 082B43A67AA for ; Thu, 26 Feb 2009 00:36:12 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBA89C003E; Thu, 26 Feb 2009 09:36:32 +0100 (CET) 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 G9xTQgcFgR5e; Thu, 26 Feb 2009 09:36:26 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7E73C0016; Thu, 26 Feb 2009 09:36:26 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id CC3849AFBDE; Thu, 26 Feb 2009 09:36:25 +0100 (CET) Date: Thu, 26 Feb 2009 09:36:25 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090226083625.GD29756@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: WashamFan , Rainer Gerhards , opsawg@ietf.org References: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> <20090225170548.GA29067@elstar.iuhb02.iu-bremen.de> 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] syslogMsgSDTable, syslog-msg-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 08:36:13 -0000 On Thu, Feb 26, 2009 at 11:32:30AM +0800, WashamFan wrote: > It seems more issues to be handled when we put complicated thing > like SNMP upon simple thing like syslog. Complicated and simple? Both protocols at the end carry name/value pairs. One of two has them ordered, the other does not maintain an order. Both protocols have size constraints due to their UDP transports. I fail to see a big difference in complexity/simplicity. > I think SNMP messages go through syslog tunnel may lose some > information, now. Yes, and mind you that truncation is a normal part of life of a SYSLOG message. On the other hand, the majority of SNMP notifications are really short, mainly due to the 484 guaranteed SNMP message size over UDP. The SYSLOG UDP transport says receivers SHOULD be able to receive datagrams with messages size of up to 2048 octets. For SNMP, it is recommended that implementations be capable of accepting messages of up to 1472 octets in size. So the situation is not really so bad, but we should still keep the SD encoding compact. And for corner case situations, you have to pick a different transport. And essentially this text needs to be added is some nicer words to the documents, as suggested by Rainer. /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 Thu Feb 26 00:59:56 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 E724F3A6BD4 for ; Thu, 26 Feb 2009 00:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, 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 gBG0LWy5ycIz for ; Thu, 26 Feb 2009 00:59:56 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id EE8803A6806 for ; Thu, 26 Feb 2009 00:59:55 -0800 (PST) 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 <0KFO0055M10EFS60@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 17:00:14 +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 <0KFO001PS10CZ700@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 17:00:14 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 26 Feb 2009 17:00:12 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 26 Feb 2009 17:00:12 +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: <20090226083434.GC29756@elstar.iuhb02.iu-bremen.de> References: <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090218130036.GA9430@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090226083434.GC29756@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 26 Feb 2009 08:59:57 -0000 > On Thu, Feb 26, 2009 at 11:25:42AM +0800, WashamFan wrote: > > > How many parameters do you like to define? v1-v100, d1-d100,...? > > I will define them without putting an explicit upper bound into place. > OK.It seems no text to prohibit unlimited numbers of params appearing in a SDE, so I assume it is allowed for by syslog-protocol. washam From rgerhards@gmail.com Thu Feb 26 01:07: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 591763A6BD4 for ; Thu, 26 Feb 2009 01:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 3Ei6BVciMJ+g for ; Thu, 26 Feb 2009 01:07:28 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 1E07F3A6806 for ; Thu, 26 Feb 2009 01:07:26 -0800 (PST) Received: by fxm24 with SMTP id 24so393809fxm.37 for ; Thu, 26 Feb 2009 01:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CISq025D6HGwMALKECbTe8EIB2QHAhrI1bXCTwKdZo4=; b=stQ918bxE+pekuGnhs57jxc5MEP4UkiwmL1N7YOb57TTNT476WT7dvyZfko6XNKhWd KwF9NMfVXFiHS86mMzc1xb9LatmO6O70qtxrSKeOkHtj9889YOjURvjuXibgKf55pNKa Cn094BjrZAiuprY0o74vfgRjVXEnzb0mvq9q8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uYCQ5jteB0mvxDWPL/kxtMEDj869yzMIbXfonC5uUlS0BGXsbT7kJoGr/ow69mSM5W pIkufp7NVJ8AOtJv7Eb/qc9KSEwYWM5fqHITwtVzMiYSXdq9/4UhMKNHpMg9vJ6z+1ng z7+zuyNDjpnZcXD2Ob61l01RvBszlNw7eNMEg= MIME-Version: 1.0 Received: by 10.181.158.3 with SMTP id k3mr375790bko.134.1235639267559; Thu, 26 Feb 2009 01:07:47 -0800 (PST) In-Reply-To: References: <20090218103058.GD8933@elstar.iuhb02.iu-bremen.de> <20090224162824.GC26471@elstar.iuhb02.iu-bremen.de> <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090226083434.GC29756@elstar.iuhb02.iu-bremen.de> Date: Thu, 26 Feb 2009 10:07:47 +0100 Message-ID: From: Rainer Gerhards To: WashamFan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 26 Feb 2009 09:07:29 -0000 On Thu, Feb 26, 2009 at 10:00 AM, WashamFan wrote: >> On Thu, Feb 26, 2009 at 11:25:42AM +0800, WashamFan wrote: >> >> =A0> How many parameters do you like to define? v1-v100, d1-d100,...? >> >> =A0I will define them without putting an explicit upper bound into place= . >> > > OK.It seems no text to prohibit unlimited numbers of params appearing in > a SDE, so I assume it is allowed for by syslog-protocol. It is not prohibited and I can not envision why an implementation should have an issue with that. In practice, however, the size limitations put an implicit upper limit on the number of parameters. But that is a general issue, nothing to be addressed in the context of the encoding here. Rainer From rgerhards@gmail.com Thu Feb 26 01:19: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 7FBDC3A6806 for ; Thu, 26 Feb 2009 01:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 sfXThoTyFEC5 for ; Thu, 26 Feb 2009 01:19:39 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 1AF613A6998 for ; Thu, 26 Feb 2009 01:19:38 -0800 (PST) Received: by bwz26 with SMTP id 26so393205bwz.37 for ; Thu, 26 Feb 2009 01:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=OtCTC2MHANxIrrKerWxVClMFGO/31ETEb9K6GE/1MjU=; b=NX12jhUsO0AcP4CFGKHbNYMcYcdB191uh3RO04h875CjFNMeuczj0XMLxYl7ToFOqS OBLY8c9u8i6Ev/JAMAuTgHIiKF9FVoLQghfkpgPECRRQ+9MHlKIijhfawuZd0HwBrDIB v+HcGY6gKtZg9Gqyz3Fi//wSJhSjJCh+254zM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=i8enOO02T8s+3byHJsOXKf2NSX1M35bOXZtbvb0OChFxkpUJ63qrZgChZ5oFJywpfK 5Ky1onLBmMFV5KI33cGJLmRivauhCcYjmyxrZGOCjwgH1ytdvztnjamJr0ujYV448DFK MA0sox1jiNi3hfc4BiMNnXlsRoBkQJafP9d/k= MIME-Version: 1.0 Received: by 10.180.218.15 with SMTP id q15mr375076bkg.194.1235639999254; Thu, 26 Feb 2009 01:19:59 -0800 (PST) In-Reply-To: <20090226083625.GD29756@elstar.iuhb02.iu-bremen.de> References: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> <20090225170548.GA29067@elstar.iuhb02.iu-bremen.de> <20090226083625.GD29756@elstar.iuhb02.iu-bremen.de> Date: Thu, 26 Feb 2009 10:19:56 +0100 Message-ID: From: Rainer Gerhards To: j.schoenwaelder@jacobs-university.de, WashamFan , Rainer Gerhards , opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 26 Feb 2009 09:19:40 -0000 On Thu, Feb 26, 2009 at 9:36 AM, Juergen Schoenwaelder wrote: > On Thu, Feb 26, 2009 at 11:32:30AM +0800, WashamFan wrote: > >> It seems more issues to be handled when we put complicated thing >> like SNMP upon simple thing like syslog. > > Complicated and simple? Both protocols at the end carry name/value > pairs. One of two has them ordered, the other does not maintain an > order. Both protocols have size constraints due to their UDP > transports. I fail to see a big difference in complexity/simplicity. > >> I think SNMP messages go through syslog tunnel may lose some >> information, now. > > Yes, and mind you that truncation is a normal part of life of a SYSLOG > message. On the other hand, the majority of SNMP notifications are > really short, mainly due to the 484 guaranteed SNMP message size over > UDP. The SYSLOG UDP transport says receivers SHOULD be able to receive > datagrams with messages size of up to 2048 octets. For SNMP, it is > recommended that implementations be capable of accepting messages of > up to 1472 octets in size. Thank for spelling out these numbers. Being not involved in SNMP, I did not have them on my mind. Now I agree that this should be not so much of an issue. The main thing is the BER is more compact than SD-IDs. > So the situation is not really so bad, but we should still keep the SD > encoding compact. And for corner case situations, you have to pick a > different transport. And essentially this text needs to be added is > some nicer words to the documents, as suggested by Rainer. I suggest the following: - use a compact encoding, what is provided already looks good - suggest that a translator by default drops optional human-readable parts if the syslog message would go beyond a specific size (2K seems like a good default) - suggest to put more important parameters early in the syslog message. If a syslog receiver truncates and processes the message, it is specified that the end of the message must be truncated. Thus, putting the important parts first enhances the chance they will not get truncated - add a note to operators that they should configure the syslog subsystem with reasonable max message sizes The last suggestion, I think, requires some explanation: syslog-protocol does not set any upper limit on syslog message sizes. This is left to the transports and WG consensus was that we put no explicit upper boound in any transport unless strictly necessary. This was done to allow some use cases (IHE, Windows event forwarding) that require much larger messages (64K+ may be required in some cases). I expect that all major syslog implementations will support configurable max sizes. I also expect that only few operators will actually now about this feature. My expectation is that product that require larger sizes will include that in their operator manual. In that spirit, I think it would be good to hint SNMP/syslog translator implementors/deployers on the size issue and the potential work-around. If someone actually tunnels SNMP via syslog, it would be appropriate to make sure that each syslog system in that tunnel supports e.g. 4K max message size, which would sufficiently address the syslog size limitation issue. Rainer From Washam.Fan@huaweisymantec.com Thu Feb 26 02:47: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 016EB28C285 for ; Thu, 26 Feb 2009 02:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 f8+QP75nKk6K for ; Thu, 26 Feb 2009 02:47:15 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id F2D5028C273 for ; Thu, 26 Feb 2009 02:47:14 -0800 (PST) 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 <0KFO0055A5Z8FS70@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 18:47:34 +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 <0KFO00GD15Z6TP10@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 26 Feb 2009 18:47:32 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 26 Feb 2009 18:47:30 +0800 From: WashamFan To: Rainer Gerhards Message-id: Date: Thu, 26 Feb 2009 18:47:30 +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: <20090225105017.GC27716@elstar.iuhb02.iu-bremen.de> <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> <20090225170548.GA29067@elstar.iuhb02.iu-bremen.de> <20090226083625.GD29756@elstar.iuhb02.iu-bremen.de> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 26 Feb 2009 10:47:16 -0000 > >> I think SNMP messages go through syslog tunnel may lose some > >> information, now. > > > > Yes, and mind you that truncation is a normal part of life of a SYSLOG > > message. On the other hand, the majority of SNMP notifications are > > really short, mainly due to the 484 guaranteed SNMP message size over > > UDP. The SYSLOG UDP transport says receivers SHOULD be able to receive > > datagrams with messages size of up to 2048 octets. For SNMP, it is > > recommended that implementations be capable of accepting messages of > > up to 1472 octets in size. > > Thank for spelling out these numbers. Being not involved in SNMP, I > did not have them on my mind. Now I agree that this should be not so > much of an issue. The main thing is the BER is more compact than > SD-IDs. I'd like to add that, SYSLOG UDP transport would not support up to 2048 octets in practice due to IP fragmentation avoidance. As I know, majority of syslog information are short, too. According to syslog-transport-udp, 480 octets and 1180 octets are MUST for IPv4 and IPv6 respectively, 2048 octets are recommended. washam From rgerhards@gmail.com Thu Feb 26 02:57: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 472793A696D for ; Thu, 26 Feb 2009 02:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 1-9IBcn1HUJp for ; Thu, 26 Feb 2009 02:57:28 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id D9CD13A6953 for ; Thu, 26 Feb 2009 02:57:27 -0800 (PST) Received: by mail-bw0-f178.google.com with SMTP id 26so435869bwz.37 for ; Thu, 26 Feb 2009 02:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DKx/2Yu2Wj/dW+nmURTwzQgMW6HhSiwS0Hzvw2CdVCk=; b=SSIXzivJ7tfitUvl57YW6ixMhVw52OzHJM608h4c838A2U6i0FoFe/PD3N1KkA3P4d 4iaers9gJ175/NCzW0mUXhqiJln8y7RqNvyKy7BkkieYBai2/BZMSTMeODv5n7S24go+ zWMH5HoxI3NORgjEVNnzhUnLhj4hLBMgmR2fE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=abrav9cBwEGPTMBEkDaUCTMRvCru4BW8dPHxWeRQWde9mYCo9tsPmzpkILF6NnzIQ4 NEQFtSR2XuKFPnXLoHohv4aGPC5LMbJWG28yzf/KbY9Cu/GNt4U54A23MPnreXP3JZQ+ v1Aznp0E1YsHgoU1kqhpV/o8/1b00iRMtQ11M= MIME-Version: 1.0 Received: by 10.181.135.5 with SMTP id m5mr416312bkn.33.1235645869084; Thu, 26 Feb 2009 02:57:49 -0800 (PST) In-Reply-To: References: <20090225155345.GA28972@elstar.iuhb02.iu-bremen.de> <20090225170548.GA29067@elstar.iuhb02.iu-bremen.de> <20090226083625.GD29756@elstar.iuhb02.iu-bremen.de> Date: Thu, 26 Feb 2009 11:57:48 +0100 Message-ID: From: Rainer Gerhards To: WashamFan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsawg@ietf.org Subject: Re: [OPSAWG] syslogMsgSDTable, syslog-msg-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: Thu, 26 Feb 2009 10:57:29 -0000 On Thu, Feb 26, 2009 at 11:47 AM, WashamFan wrote: > >> =A0>> I think SNMP messages go through syslog tunnel may lose some >> =A0>> information, now. >> =A0> >> =A0> Yes, and mind you that truncation is a normal part of life of a SYS= LOG >> =A0> message. On the other hand, the majority of SNMP notifications are >> =A0> really short, mainly due to the 484 guaranteed SNMP message size ov= er >> =A0> UDP. The SYSLOG UDP transport says receivers SHOULD be able to rece= ive >> =A0> datagrams with messages size of up to 2048 octets. For SNMP, it is >> =A0> recommended that implementations be capable of accepting messages o= f >> =A0> up to 1472 octets in size. >> >> =A0Thank for spelling out these numbers. Being not involved in SNMP, I >> =A0did not have them on my mind. Now I agree that this should be not so >> =A0much of an issue. The main thing is the BER is more compact than >> =A0SD-IDs. > I'd like to add that, SYSLOG UDP transport would not support up to 2048 o= ctets > in practice due to IP fragmentation avoidance. As I know, majority of sys= log > information are short, too. According to syslog-transport-udp, 480 octets= and > 1180 octets are MUST for IPv4 and IPv6 respectively, 2048 octets are reco= mmended. Well, actually UDP syslog works well up to 4K on many platforms. I did a quick survey, never fully completed, while we worked on syslog-protocol. It can be found here: http://www.monitorware.com/Common/en/articles/ihe-syslog.php But as you say, 480 is the only guaranteed size. In practical implementations, I'd expect that 2K is used for UDP, too. But under network stress conditions, anything larger than 480 octets may have more trouble reaching the destination. Rainer From rgerhards@gmail.com Thu Feb 26 03:20:47 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 731EB3A6AE7; Thu, 26 Feb 2009 03:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 j5gcY1c604rV; Thu, 26 Feb 2009 03:20:46 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id D6EF63A6AB8; Thu, 26 Feb 2009 03:20:45 -0800 (PST) Received: by bwz26 with SMTP id 26so445495bwz.37 for ; Thu, 26 Feb 2009 03:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wuMFqv19pynKW1jvoqpqRjLu10DmZxeDJcai4yLDY44=; b=k/5u0iOFFTLsFzdlg50UEN1ZGK0UKZ/0Hlx5754cUditn/5DuQdSp7AO7cNn/jxFhU nSAQlwu86Povzu6eBJOpnwAKY246v9KLabbJsqSQ8fwFnvk4t8iUnVnZJkIX18H67w6X evi7yJkUXLiyFxAKPss/3L28B5RaaJ3l1qd3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FRIaLnhcGbw6BBwALtu/swhqJU+7N7eU2zgg5YpjuJu597qrfffqDcSoovsLlOlXWq JvQOC1Zd8DUstQEWLUjo0zeFi9E8Gi3L9QBJrIvt70Xdj++Q2UM7bLvdYlw9pcPQcmcx dw+qUgpE2zte3jstJppc8OPLZe895pcU/G2X8= MIME-Version: 1.0 Received: by 10.181.146.14 with SMTP id y14mr420904bkn.70.1235647265999; Thu, 26 Feb 2009 03:21:05 -0800 (PST) In-Reply-To: <0b7a01c99781$ab3396b0$0600a8c0@china.huawei.com> References: <0b7a01c99781$ab3396b0$0600a8c0@china.huawei.com> Date: Thu, 26 Feb 2009 12:21:05 +0100 Message-ID: From: Rainer Gerhards To: David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] FW: I-D ACTION:draft-feng-syslog-transport-dtls-00.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: Thu, 26 Feb 2009 11:20:47 -0000 I have not yet looked at the new draft, but here has been prior work by Tom Petch and me in this direction: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg11459.html It may make sense to merge the two efforts. Rainer 2009/2/25 David Harrington : > FYI > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, February 25, 2009 1:30 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-feng-syslog-transport-dtls-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Transmission of SYSLOG message= over DTLS > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Feng > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-feng-syslog-transport-dtls= -00.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 10 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-2-25 > > =A0 This document describes a Transport for the Syslog Protocol, which > =A0 uses the Datagram Transport Layer Security (DTLS) protocol. =A0The > DTLS > =A0 protocol provides authentication and privacy services for SYSLOG > =A0 applications. =A0This document describes how using DTLS to transport > =A0 SYSLOG messages makes this protection possible in an interoperable > =A0 way. > > =A0 This transport is designed to meet the security and operational > needs > =A0 of network administrators, operate in environments where a > =A0 connectionless (UDP) transport is preferred, and integrates well > into > =A0 existing public keying infrastructures. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-feng-syslog-transport-dtls-0 > 0.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From dromasca@avaya.com Thu Feb 26 05:40:23 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 DF62C28C0CF for ; Thu, 26 Feb 2009 05:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 gCNYLrtL3jsc for ; Thu, 26 Feb 2009 05:40:23 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5567428C11A for ; Thu, 26 Feb 2009 05:40:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,271,1233550800"; d="scan'208,217";a="138654932" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Feb 2009 08:40:41 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Feb 2009 08:40:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99817.D02FE051" Date: Thu, 26 Feb 2009 14:40:38 +0100 Message-ID: In-Reply-To: <013301c997d4$434f4820$3682990a@h3c.huawei3com.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] I would like to extend ENTITY-MIB (rfc4133)... Thread-Index: AcmX1ElcsqM0K5FMRMG1teRUFKhVWwAQn+7Q References: <013301c997d4$434f4820$3682990a@h3c.huawei3com.com> From: "Romascanu, Dan (Dan)" To: "Shimin Ban" , Subject: Re: [OPSAWG] I would like to extend ENTITY-MIB (rfc4133)... 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, 26 Feb 2009 13:40:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99817.D02FE051 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Shimin Ban, =20 Please see in-line.=20 =20 Regards, =20 Dan =20 ________________________________ From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Shimin Ban Sent: Thursday, February 26, 2009 7:37 AM To: opsawg@ietf.org Subject: [OPSAWG] I would like to extend ENTITY-MIB (rfc4133)... =09 =09 Hello, I would like to extend RFC4133. I'ld like to add the following information to entity MIB: =20 (1) The absolute position of the entity in its parent According to the absolute position and the information provided by entity MIB, the NMS can display the panel of devices easily regardless of vendor. The customer could monitor the status of the entity easily through the panel. But the entity MIB does not provide the entity status information. [DR] You probably need to provide more information about what you mean by 'absolute position'. Is this about order (like first card, second card, etc.) or even more - like exact coordinates on a panel drawing?=20 =20 Depending on your answers other folks writing similar applications could comment if representing such information in the MIB of the device is important enough to be included in an extension of the Entity MIB.=20 =20 (2) The status of the entity [DR] Is the information in the Entity State MIB (RFC 4268) not sufficient?=20 =20 =20 (3) The other important information of CPU, Sensor, disk, powersupply etc. [DR] Is the information in the Entity Sensor MIB (RFC 3433) not sufficient?=20 =20 Can the ENTITY-MIB be extended? What needs to happen?=20 [DR] The OPSAWG can be a home for working on such extensions if there is interest here. Let us see what other people think.=20 =20 Thank you very much. =20 Cheers Shimin Ban =20 =20 =20 ------_=_NextPart_001_01C99817.D02FE051 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Shimin Ban,
 
Please see in-line.
 
Regards,
 
Dan
 

From: opsawg-bounces@ietf.org=20 [mailto:opsawg-bounces@ietf.org] On Behalf Of Shimin=20 Ban
Sent: Thursday, February 26, 2009 7:37 AM
To:=20 opsawg@ietf.org
Subject: [OPSAWG] I would like to extend = ENTITY-MIB=20 (rfc4133)...

Hello,
I would like to extend RFC4133. I'ld like to = add the=20 following information to entity MIB:
 
(1) The absolute position of the entity in its=20 parent
According to the absolute position and the = information=20 provided by entity MIB, the NMS can display the panel of devices = easily=20 regardless of vendor.
The customer could monitor the status of the = entity easily=20 through the panel. But the entity MIB does not provide the entity = status=20 information.
[DR] You probably need to provide more = information about=20 what you mean by 'absolute position'. Is this about order (like first = card,=20 second card, etc.) or even more - like exact coordinates on a panel = drawing?=20
 =
Depending on your answers other = folks writing similar applications could comment if = representing=20 such information in the MIB of the device is important enough to be = included=20 in an extension of the Entity MIB.
 =
(2) The status of the entity
[DR] Is the information in the Entity State MIB = (RFC 4268)=20 not sufficient?
 =
 
(3) The other important information of CPU, = Sensor, disk,=20 powersupply etc.
[DR] Is the information in the = Entity Sensor MIB=20 (RFC 3433)  not sufficient?=20
 
Can the ENTITY-MIB be extended? What needs to = happen?=20
[DR] The OPSAWG can be a home for working on such = extensions if there is interest here. Let us see what other people = think.=20
 
Thank you very much.
 
Cheers
Shimin Ban
 
 
 
------_=_NextPart_001_01C99817.D02FE051-- From j.schoenwaelder@jacobs-university.de Thu Feb 26 05:44:39 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 197543A692E for ; Thu, 26 Feb 2009 05:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_12=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 C3h73TOp03HV for ; Thu, 26 Feb 2009 05:44:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E6B893A68F6 for ; Thu, 26 Feb 2009 05:44:37 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C803C006F; Thu, 26 Feb 2009 14:44:59 +0100 (CET) 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 jSbQqgQkJKZj; Thu, 26 Feb 2009 14:44:53 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C616C0016; Thu, 26 Feb 2009 14:44:53 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id E6B4B9CF055; Thu, 26 Feb 2009 14:44:51 +0100 (CET) Date: Thu, 26 Feb 2009 14:44:51 +0100 From: Juergen Schoenwaelder To: Shimin Ban Message-ID: <20090226134451.GB17668@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Shimin Ban , opsawg@ietf.org References: <013301c997d4$434f4820$3682990a@h3c.huawei3com.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013301c997d4$434f4820$3682990a@h3c.huawei3com.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I would like to extend ENTITY-MIB (rfc4133)... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:44:39 -0000 On Thu, Feb 26, 2009 at 01:37:07PM +0800, Shimin Ban wrote: > I would like to extend RFC4133. I'ld like to add the following > information to entity MIB: > > (1) The absolute position of the entity in its parent > According to the absolute position and the information provided by entity MIB, the NMS can display the panel of devices easily regardless of vendor. > The customer could monitor the status of the entity easily through the panel. But the entity MIB does not provide the entity status information. > (2) The status of the entity > (3) The other important information of CPU, Sensor, disk, powersupply etc. > > Can the ENTITY-MIB be extended? What needs to happen? I think it helps if you write an Internet-Draft explaining the MIB extentions you have in your mind in some more detail. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103