From dromasca@avaya.com Wed Apr 4 07:50:56 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22AB21F852D; Wed, 4 Apr 2012 07:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLecXFCEl6YN; Wed, 4 Apr 2012 07:50:55 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 68AA621F851A; Wed, 4 Apr 2012 07:50:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAP5efE/GmAcF/2dsb2JhbABFuB2BB4ILAQEBAhIeCj8SARUVBgwMB1cBBBsBEgeHZwueIptuiw2EZGMEm3WKHoJpgVI X-IronPort-AV: E=Sophos;i="4.75,370,1330923600"; d="scan'208";a="2856940" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Apr 2012 10:50:52 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Apr 2012 10:49:32 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Bxv6 Fg33 KecC LsRV Mnkp Ne7o PVPk QBqB QVMl QnE8 SG4m VQlJ Vgdm Vvmn WbIP XsxP; 2; ZQBtAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA7AG0AaQBiAC0AZABvAGMAdABvAHIAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {F66BBF7D-3745-40F6-9ECF-28D710AEDEFF}; ZAByAG8AbQBhAHMAYwBhAEAAYQB2AGEAeQBhAC4AYwBvAG0A; Wed, 04 Apr 2012 14:50:45 GMT; RQBuAHQAaQB0AHkAIABNAEkAQgB2ADQAPwA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {F66BBF7D-3745-40F6-9ECF-28D710AEDEFF} Content-class: urn:content-classes:message Date: Wed, 4 Apr 2012 16:50:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Entity MIBv4? Thread-Index: Ac0SclCuvMhGdm48QlyBzsYXEyxfkg== From: "Romascanu, Dan (Dan)" To: "MIB Doctors" Cc: eman@ietf.org Subject: [MIB-DOCTORS] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:50:56 -0000 Hi MIB Doctors, I am not sure how many of you follow the EMAN WG which has a chartered item for a Power and Energy Monitoring MIB - http://www.ietf.org/id/draft-ietf-eman-energy-monitoring-mib-02.txt. One of the issue they are encountering is the need to support a small subset of objects from the Entity MIB composed of entPhysicalIndex, entPhysicalName and entPhysicalUris (which in their case is read-only and limited size). Full support of the Entity MIB as per RFC 4133 may happen but they estimate it would be an extra-load for the devices reporting power and energy information. A proposal was made to define the subset of objects they need as a module compliance for small energy reporting devices to be defined for the Entity MIB (see slides 8 and 9 in http://www.ietf.org/proceedings/83/slides/slides-83-eman-3.pdf).=20 My question is whether you see such a solution causing any problem?=20 Is it worth a v4 for the Entity MIB, or could it be done differently?=20 Thanks and Regards, Dan From j.schoenwaelder@jacobs-university.de Wed Apr 4 08:18:16 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABCD21F8628; Wed, 4 Apr 2012 08:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.841 X-Spam-Level: X-Spam-Status: No, score=-102.841 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya6FGcCnAl4d; Wed, 4 Apr 2012 08:18:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D5B0A21F861D; Wed, 4 Apr 2012 08:18:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD93D20C4B; Wed, 4 Apr 2012 17:18:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YUH5fP5NBbUZ; Wed, 4 Apr 2012 17:18:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5449920BDD; Wed, 4 Apr 2012 17:18:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EF7EC1E2E6DA; Wed, 4 Apr 2012 17:18:13 +0200 (CEST) Date: Wed, 4 Apr 2012 17:18:13 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120404151813.GC14437@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , MIB Doctors , eman@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.21 (2010-09-15) Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:18:16 -0000 On Wed, Apr 04, 2012 at 04:50:45PM +0200, Romascanu, Dan (Dan) wrote: > Hi MIB Doctors, > > I am not sure how many of you follow the EMAN WG which has a chartered > item for a Power and Energy Monitoring MIB - > http://www.ietf.org/id/draft-ietf-eman-energy-monitoring-mib-02.txt. One > of the issue they are encountering is the need to support a small subset > of objects from the Entity MIB composed of entPhysicalIndex, > entPhysicalName and entPhysicalUris (which in their case is read-only > and limited size). Full support of the Entity MIB as per RFC 4133 may > happen but they estimate it would be an extra-load for the devices > reporting power and energy information. A proposal was made to define > the subset of objects they need as a module compliance for small energy > reporting devices to be defined for the Entity MIB (see slides 8 and 9 > in http://www.ietf.org/proceedings/83/slides/slides-83-eman-3.pdf). > > My question is whether you see such a solution causing any problem? > Is it worth a v4 for the Entity MIB, or could it be done differently? Well, the IMHO biggest reason to spin the Entity MIB is to move the physical class TC to IANA. EMAN also deals with batteries that there is no proper physical class for it. /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 Wed Apr 4 08:21:15 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB9121F87C1; Wed, 4 Apr 2012 08:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR9Bt5CCmVkh; Wed, 4 Apr 2012 08:21:13 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 663B821F8628; Wed, 4 Apr 2012 08:21:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJRlfE+HCzI1/2dsb2JhbABFuB+BB4IJAQEBAQECEh4KPwwEAgEIDQECAQQBAQEKBgwLAQYBRQkIAQEEEwgBEgeHZwueIptuiw2EZGMElnSFAYoegmmBUg X-IronPort-AV: E=Sophos;i="4.75,370,1330923600"; d="scan'208";a="300427968" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Apr 2012 11:21:11 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Apr 2012 11:05:06 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 17:21:08 +0200 Message-ID: In-Reply-To: <20120404151813.GC14437@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0SdiqXVWDVVFTqQTeFNMun9MTsMwAAByFg References: <20120404151813.GC14437@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:21:16 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, April 04, 2012 6:18 PM > To: Romascanu, Dan (Dan) > Cc: MIB Doctors; eman@ietf.org > Subject: Re: [eman] Entity MIBv4? >=20 > On Wed, Apr 04, 2012 at 04:50:45PM +0200, Romascanu, Dan (Dan) wrote: > > Hi MIB Doctors, > > > > I am not sure how many of you follow the EMAN WG which has a > chartered > > item for a Power and Energy Monitoring MIB - > > http://www.ietf.org/id/draft-ietf-eman-energy-monitoring-mib-02.txt. > One > > of the issue they are encountering is the need to support a small > subset > > of objects from the Entity MIB composed of entPhysicalIndex, > > entPhysicalName and entPhysicalUris (which in their case is read-only > > and limited size). Full support of the Entity MIB as per RFC 4133 may > > happen but they estimate it would be an extra-load for the devices > > reporting power and energy information. A proposal was made to define > > the subset of objects they need as a module compliance for small > energy > > reporting devices to be defined for the Entity MIB (see slides 8 and > 9 > > in http://www.ietf.org/proceedings/83/slides/slides-83-eman-3.pdf). > > > > My question is whether you see such a solution causing any problem? > > Is it worth a v4 for the Entity MIB, or could it be done differently? >=20 > Well, the IMHO biggest reason to spin the Entity MIB is to move the > physical class TC to IANA. EMAN also deals with batteries that there > is no proper physical class for it. >=20 > /js >=20 [[DR]] Right, this too.=20 However, this would not be controversial (I believe) while the proposal to define a compliance for a small subset of objects may raise some brows.=20 Dan From bertietf@bwijnen.net Wed Apr 4 08:39:10 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65E921F8604; Wed, 4 Apr 2012 08:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj-DCe7tFJ1h; Wed, 4 Apr 2012 08:39:09 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id B7BD721F85C5; Wed, 4 Apr 2012 08:39:08 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SFSIa-0006tm-Tq; Wed, 04 Apr 2012 17:39:06 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SFSIa-0000D3-LQ; Wed, 04 Apr 2012 17:39:04 +0200 Message-ID: <4F7C6B18.5010806@bwijnen.net> Date: Wed, 04 Apr 2012 17:39:04 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120404151813.GC14437@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c6105ed596b75aa3b0f2acd2578b1762 Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:39:10 -0000 On 4/4/12 5:21 PM, Romascanu, Dan (Dan) wrote: > [[DR]] Right, this too. > > However, this would not be controversial (I believe) while the proposal > to define a compliance for a small subset of objects may raise some > brows. WHy would that raise brows? I think it is fine to define one more (limited) module compliance, as long as you are clear about what it is, what it is useful for and possibly some statements as to which environments would be the appropriate place for them (ala sort of a Applicabilty Statement; which could be in the DESCRIPTION clause I would think). Bert From adrian@olddog.co.uk Sun Apr 8 13:34:55 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7389021F84FB for ; Sun, 8 Apr 2012 13:34:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo-Vn76uynIF for ; Sun, 8 Apr 2012 13:34:55 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A62AA21F84FE for ; Sun, 8 Apr 2012 13:34:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q38KYr54020289; Sun, 8 Apr 2012 21:34:53 +0100 Received: from 950129200 (AGrenoble-551-1-55-195.w86-197.abo.wanadoo.fr [86.197.14.195]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q38KYpng020274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Apr 2012 21:34:52 +0100 From: "Adrian Farrel" To: , Date: Sun, 8 Apr 2012 21:34:48 +0100 Message-ID: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0Vxo5GJkZRQl0HTtWVClJ8eBWjEA== Content-Language: en-gb Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org Subject: [MIB-DOCTORS] Help with conformance statements X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 20:34:55 -0000 Hi, Is there a MIB Doctor that can help us? I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt It reads... > I would like help from the OPS ADs (and MIB Doctors) on this point: > > It seems to me that section 6.7 needs a new conformance statement to > be applied to ISIS-MIB. The text in the section appears to be in two > parts: > > - Implementation guidance (what value to return on a GET from a Trill > implementation) > > - Implementation requirements (which tables/objects to implement or > not (conformance statement). Can anyone tell me if I am right or wrong. Thanks, Adrian From mrm@vmware.com Mon Apr 9 14:39:09 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5BB21F880C for ; Mon, 9 Apr 2012 14:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4+HhdrKjG7T for ; Mon, 9 Apr 2012 14:39:08 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id C447221F87FF for ; Mon, 9 Apr 2012 14:39:07 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 9B0DC281AF for ; Mon, 9 Apr 2012 14:39:06 -0700 (PDT) Received: from zimbra-prod-mta-3.vmware.com (zimbra-prod-mta-3.vmware.com [10.113.160.227]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 97252B00FB for ; Mon, 9 Apr 2012 14:39:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-prod-mta-3.vmware.com (Postfix) with ESMTP id 92A90FF129 for ; Mon, 9 Apr 2012 14:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra-prod-mta-3.vmware.com Received: from zimbra-prod-mta-3.vmware.com ([127.0.0.1]) by localhost (zimbra-prod-mta-3.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixpjlZjttdOS for ; Mon, 9 Apr 2012 14:39:06 -0700 (PDT) Received: from zimbra-prod-mbox-2.vmware.com (zimbra-prod-mbox-2.vmware.com [10.113.160.202]) by zimbra-prod-mta-3.vmware.com (Postfix) with ESMTP id 8166EFF112 for ; Mon, 9 Apr 2012 14:39:06 -0700 (PDT) Date: Mon, 9 Apr 2012 14:39:06 -0700 (PDT) From: Michael MacFaden To: mib-doctors@ietf.org Message-ID: <1574281210.1747740.1334007546413.JavaMail.root@zimbra-prod-mbox-2.vmware.com> In-Reply-To: <459625917.1591410.1333650558199.JavaMail.root@zimbra-prod-mbox-2.vmware.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1747739_1964939128.1334007546412" X-Originating-IP: [10.113.60.13] X-Mailer: Zimbra 7.1.3_GA_3374 (ZimbraWebClient - GC18 (Mac)/7.1.3_GA_3346) X-Mailman-Approved-At: Mon, 09 Apr 2012 14:51:39 -0700 Subject: [MIB-DOCTORS] Fwd: Qestion about RFC 5676 and RFC 5427 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 21:39:09 -0000 ------=_Part_1747739_1964939128.1334007546412 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit all, I thought there was a MIB module for monitoring SYSLOG but all I seem to find is a TC mib 5427 and the Syslog->SNMP notification mib. What's the story? Mike ------=_Part_1747739_1964939128.1334007546412 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
all,


I thought there was a MIB module for monitoring SYSLOG
but all I seem to find is a TC mib 5427 and the Syslog->SNMP notification
mib.

What's the story?

Mike


------=_Part_1747739_1964939128.1334007546412-- From j.schoenwaelder@jacobs-university.de Tue Apr 10 01:26:12 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D5F21F87F1 for ; Tue, 10 Apr 2012 01:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.086 X-Spam-Level: X-Spam-Status: No, score=-103.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuiUxmcdaiBK for ; Tue, 10 Apr 2012 01:26:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 57A8321F87EB for ; Tue, 10 Apr 2012 01:26:11 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35B7D20C11; Tue, 10 Apr 2012 10:26:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vHBzIc6N_2BQ; Tue, 10 Apr 2012 10:26:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C68F20BE6; Tue, 10 Apr 2012 10:26:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DD8241E5B21B; Tue, 10 Apr 2012 10:26:10 +0200 (CEST) Date: Tue, 10 Apr 2012 10:26:10 +0200 From: Juergen Schoenwaelder To: Michael MacFaden Message-ID: <20120410082610.GA23757@elstar.local> Mail-Followup-To: Michael MacFaden , mib-doctors@ietf.org References: <459625917.1591410.1333650558199.JavaMail.root@zimbra-prod-mbox-2.vmware.com> <1574281210.1747740.1334007546413.JavaMail.root@zimbra-prod-mbox-2.vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1574281210.1747740.1334007546413.JavaMail.root@zimbra-prod-mbox-2.vmware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] Fwd: Qestion about RFC 5676 and RFC 5427 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:26:12 -0000 On Mon, Apr 09, 2012 at 02:39:06PM -0700, Michael MacFaden wrote: > > > > all, > > > > > I thought there was a MIB module for monitoring SYSLOG > but all I seem to find is a TC mib 5427 and the Syslog->SNMP notification > mib. > > > What's the story? There was http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 but it never really took off - perhaps the attempt to model configuration objects given that some syslog implementations allow to do pretty wild things was a mistake. The data tracker history is here: https://datatracker.ietf.org/doc/draft-ietf-syslog-device-mib/history/ /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 Apr 10 01:53:22 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2253221F872F for ; Tue, 10 Apr 2012 01:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSOlaWyo9n9h for ; Tue, 10 Apr 2012 01:53:21 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 30FB121F866C for ; Tue, 10 Apr 2012 01:53:21 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SHWpA-0003GN-Ua; Tue, 10 Apr 2012 10:53:18 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SHWpA-0004IB-GV; Tue, 10 Apr 2012 10:53:16 +0200 Message-ID: <4F83F4FB.3010005@bwijnen.net> Date: Tue, 10 Apr 2012 10:53:15 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk> In-Reply-To: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4d1bb29633fd72ea74fb270669b4531b7 Cc: mib-doctors@ietf.org, draft-ietf-trill-rbridge-mib@tools.ietf.org, ops-ads@tools.ietf.org Subject: Re: [MIB-DOCTORS] Help with conformance statements X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:53:22 -0000 From a quick read that I did (section 6.7), then it indeed seems to specify a set of requirements (even in MUST) language for the ISIS-MIB module. So here (in sect 6.7) they are described in English. It would indeed be useful to have that documented in machine readable format, i.e. in (or as part of) a MODULE-COMPLIANCE statement. Is it a reason to hold up the document? Not sure about that. At the time when I was AD, I tried to strongly encourage people to express such requirements in the form of MODULE_COMPLIANCE statements. But that was/is my view. Maybe other MIB doctors do have an opinion on that. Bert On 4/8/12 10:34 PM, Adrian Farrel wrote: > Hi, > > Is there a MIB Doctor that can help us? > > I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt > > It reads... > >> I would like help from the OPS ADs (and MIB Doctors) on this point: >> >> It seems to me that section 6.7 needs a new conformance statement to >> be applied to ISIS-MIB. The text in the section appears to be in two >> parts: >> >> - Implementation guidance (what value to return on a GET from a Trill >> implementation) >> >> - Implementation requirements (which tables/objects to implement or >> not (conformance statement). > > Can anyone tell me if I am right or wrong. > > Thanks, > Adrian > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From bclaise@cisco.com Tue Apr 10 05:48:50 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3921B21F85C2; Tue, 10 Apr 2012 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3Cl9TCDDDRg; Tue, 10 Apr 2012 05:48:49 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F265521F85C0; Tue, 10 Apr 2012 05:48:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3ACmmJG007145; Tue, 10 Apr 2012 14:48:48 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3ACmlfV014784; Tue, 10 Apr 2012 14:48:47 +0200 (CEST) Message-ID: <4F842C2F.4000505@cisco.com> Date: Tue, 10 Apr 2012 14:48:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: aaa-doctors@ietf.org, mib-doctors@ietf.org, YANG Doctors , ops-dir@ietf.org, IETF DNS Directorate References: <20120409225417.7582.20966.idtracker@ietfa.amsl.com> In-Reply-To: <20120409225417.7582.20966.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120409225417.7582.20966.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] UPDATED Agenda and Package for the April 12, 2012 Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:48:50 -0000 Dear all, Please find below the agenda of the April 12th IESG telechat. Please send your questions, comments and concerns before April 11th COB. Sorry for the short notice, just back from my IESG summit, the Internet Engineering Skiing Group ;-) Thanks and Regards, Benoit. -------- Original Message -------- AGENDA PACKAGE FOR 2012-04-12 IESG TELECHAT 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-oauth-v2-25 The OAuth 2.0 Authorization Protocol (Proposed Standard) Token: Stephen Farrell o draft-ietf-oauth-v2-bearer-18 The OAuth 2.0 Authorization Protocol: Bearer Tokens (Proposed Standard) Token: Stephen Farrell o draft-ietf-hokey-rfc5296bis-06 EAP Extensions for EAP Re-authentication Protocol (ERP) (Proposed Standard) Token: Stephen Farrell o draft-ietf-ippm-rt-loss-03 Round-trip Loss Metrics (Proposed Standard) Note: Document shepherd is Henk Uijterwaal (henk@uijterwaal.nl). Token: Wesley Eddy o draft-ietf-dnsext-rfc2671bis-edns0-08 Extension Mechanisms for DNS (EDNS0) (Standard) Note: Olafur Gudmundsson (ogud at ogud.com) is the document shepherd. Token: Ralph Droms o draft-ietf-avtcore-feedback-supression-rtp-16 RTCP Extension for Third-party Loss Report (Proposed Standard) Note: Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd. Token: Robert Sparks o draft-ietf-pwe3-pw-typed-wc-fec-03 LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements (Proposed Standard) Note: Andrew Malis (amalis@gmail.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-avtcore-ecn-for-rtp-07 Explicit Congestion Notification (ECN) for RTP over UDP (Proposed Standard) Note: Roni Even (even.roni@huawei.com) is the document shepherd. Token: Robert Sparks o draft-ietf-tcpm-3517bis-02 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP (Proposed Standard) Note: Pasi Sarolahti (pasi.sarolahti@iki.fi) is the document shepherd Token: Wesley Eddy o draft-ietf-dhc-dhcpv6-reconfigure-rebind-09 Rebind Capability in DHCPv6 Reconfigure Messages (Proposed Standard) Note: Ted Lemon (ted.lemon@nominum.com) is the document shepherd. Token: Brian Haberman 2.1.2 Returning Items o draft-ietf-softwire-gateway-init-ds-lite-06 Gateway Initiated Dual-Stack Lite Deployment (Proposed Standard) Note: Yong Cui (cuiyong@tsinghua.edu.cn) is the document shepherd. Token: Ralph Droms 2.2 Individual Submissions 2.2.1 New Items o draft-jivsov-openpgp-ecc-11 ECC in OpenPGP (Proposed Standard) Note: Wener Koch (wk@gnupg.org) is the Document Shepherd. Token: Sean Turner 2.2.2 Returning Items o draft-desruisseaux-caldav-sched-12 CalDAV Scheduling Extensions to WebDAV (Proposed Standard) Note: Mike Douglass - douglm@rpi.edu - is the document shepherd. Token: Barry Leiba Was deferred by Russ Housley on 2012-03-15 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-conex-concepts-uses-04 ConEx Concepts and Use Cases (Informational) Note: Nandita Dukkipati (nanditad@google.com) is the document shepherd. Token: Wesley Eddy o draft-ietf-behave-nat64-learn-analysis-03 Analysis of solution proposals for hosts to learn NAT64 prefix (Informational) Note: Dan Wing (dwing@cisco.com) is the document shepherd. Token: Wesley Eddy o draft-ietf-bmwg-ipflow-meth-09 IP Flow Information Accounting and Export Benchmarking Methodology (Informational) Note: Al Morton (acmorton@att.com) is the document shepherd. Token: Ronald Bonica o draft-ietf-ancp-pon-02 Applicability of Access Node Control Mechanism to PON based Broadband Networks (Informational) Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd. Token: Ralph Droms 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-johansson-loa-registry-04 An IANA registry for Level of Assurance (LoA) Profiles (Informational) Note: Tim Polk (tim.polk@nist.gov) is the document shepherd. Token: Sean Turner o draft-george-travel-faq-05 IETF meeting attendees' Frequently Asked (travel) Questions (Informational) Token: Russ Housley 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o draft-lear-lisp-nerd-08 NERD: A Not-so-novel EID to RLOC Database (Experimental) Token: Ralph Droms 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o v4exit (v4exit) Token: Ralph Droms o Network Virtualization Overlays (nvo3) Token: Stewart Bryant 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From mrm@vmware.com Tue Apr 10 07:19:38 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0305A21F861B for ; Tue, 10 Apr 2012 07:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pw8GbmjXO3z for ; Tue, 10 Apr 2012 07:19:37 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 51ACA21F858E for ; Tue, 10 Apr 2012 07:19:37 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 7525228257; Tue, 10 Apr 2012 07:19:36 -0700 (PDT) Received: from zimbra-prod-mta-1.vmware.com (zimbra-prod-mta-1.vmware.com [10.113.160.173]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 7169318271; Tue, 10 Apr 2012 07:19:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-prod-mta-1.vmware.com (Postfix) with ESMTP id 6C1369E0F4; Tue, 10 Apr 2012 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra-prod-mta-1.vmware.com Received: from zimbra-prod-mta-1.vmware.com ([127.0.0.1]) by localhost (zimbra-prod-mta-1.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rARCVTr7JtIR; Tue, 10 Apr 2012 07:19:36 -0700 (PDT) Received: from zimbra-prod-mbox-2.vmware.com (zimbra-prod-mbox-2.vmware.com [10.113.160.202]) by zimbra-prod-mta-1.vmware.com (Postfix) with ESMTP id 5A9879E0F0; Tue, 10 Apr 2012 07:19:36 -0700 (PDT) Date: Tue, 10 Apr 2012 07:19:36 -0700 (PDT) From: Michael MacFaden To: Juergen Schoenwaelder Message-ID: <1408021768.1783695.1334067576269.JavaMail.root@zimbra-prod-mbox-2.vmware.com> In-Reply-To: <20120410082610.GA23757@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [76.21.70.162] X-Mailer: Zimbra 7.1.3_GA_3374 (ZimbraWebClient - GC18 (Mac)/7.1.3_GA_3346) X-Mailman-Approved-At: Tue, 10 Apr 2012 07:25:15 -0700 Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] Fwd: Qestion about RFC 5676 and RFC 5427 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:19:38 -0000 What a shame the mib doesn't look half bad. Oh well back to implementing proprietary managed objects to monitor it like all the other vendors. Thanks Juergen! Mike ----- Original Message ----- > There was http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 > but it never really took off - perhaps the attempt to model > configuration objects given that some syslog implementations allow to > do pretty wild things was a mistake. The data tracker history is > here: > > https://datatracker.ietf.org/doc/draft-ietf-syslog-device-mib/history/ > > /js > From jcucchiara@mindspring.com Tue Apr 10 11:35:29 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD7A11E80FD for ; Tue, 10 Apr 2012 11:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbDxKtmXUk3z for ; Tue, 10 Apr 2012 11:35:29 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id BA41D21F84D4 for ; Tue, 10 Apr 2012 11:35:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XwJF1NtSzXsfuxvnJTHh9q7hZ59duqeC+xrmSu9ncvfi98+dzCKhbiPBRge9RJiS; h=Received:Message-ID:From:To:Cc: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 [24.41.31.146] (helo=JoanPC) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SHfuV-0003JX-BC; Tue, 10 Apr 2012 14:35:23 -0400 Message-ID: <004a01cd1748$b03f1220$6701a8c0@JoanPC> From: "Joan Cucchiara" To: "Bert Wijnen \(IETF\)" , References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk> <4F83F4FB.3010005@bwijnen.net> Date: Tue, 10 Apr 2012 14:35:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654c93ab23be5da4a24d74fbe0011ad5b527c7233ee4b332ceb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Cc: mib-doctors@ietf.org, draft-ietf-trill-rbridge-mib@tools.ietf.org, ops-ads@tools.ietf.org Subject: Re: [MIB-DOCTORS] Help with conformance statements X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:35:29 -0000 Adrian and Bert, I think it would be very helpful if the authors could specify ISIS objects in a MODULE_COMPLIANCE as Bert suggests. When I reviewed version 6 of the MIB, I asked if the authors could ensure that WG was aware there is no read-only compliance and this point was not addressed in version 7 either. Not a MUST, but certainly want to make sure that the WG is aware they need to support read-create and read-write via SNMP. Additionally, there are some warnings from the MIB compilers that were also there in version 6 and I'd like to see those addressed in the document (either discussed or fixed). My comments below were emailed to the authors. fyi, -Joan * LAST-UPDATED and REVISION clauses have the same date as Version 6 OUTPUT from SMICNGPRO ----------------------- W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have SIZE specified W: f(RBRIDGE-MIB.my), (1453,4) Row "rbridgeSnoopingAddrEntry" has indexing that may create variables with more than 128 sub-ids W: f(RBRIDGE-MIB.my), (1503,20) Item "rbridgeSnoopingAddrPorts" should have SIZE specified W: f(RBRIDGE-MIB.my), (1044,18) Row "rbridgeVlanPortEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" rbridgeBasePortEntry, since can have only one "base row" which is rbridgeVlanEntry SMILINT ----------- mibs/RBRIDGE-MIB.my:1453: [5] {index-exceeds-too-large} warning: index of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 subidentifier(s) Additional descriptions of some error/warning messages: Error: index-element-no-size (level 3) Message: index element `%s' of row `%s' must have a size restriction Description: Object identifiers are restricted in size to have at most 128 sub-identifiers. This implies that index elements used to form instance identifiers must have a size contraint which ensures that the 128 sub-identifier constraint is kept intact for any possible combination of the index elements' values (RFC 2578, Section 3.5). * Looking at the objects with TC of PortList (rbridgeMultiFibPorts, rbridgeSnoopingAddrPorts) W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have SIZE specified rbridgeMultiFibPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-only STATUS current DESCRIPTION "The list of ports to which a frame destined to this multicast distribution tree is flooded. This may be pruned further based on other forwarding information." ::= { rbridgeMultiFibEntry 2 } Q-BRIDGE-MIB defines: PortList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each octet within this value specifies a set of eight ports, with the first octet specifying ports 1 through 8, the second octet specifying ports 9 through 16, etc. Within each octet, the most significant bit represents the lowest numbered port, and the least significant bit represents the highest numbered port. Thus, each port of the bridge is represented by a single bit within the value of this object. If that bit has a value of '1' then that port is included in the set of ports; the port is not included if its bit has a value of '0'." SYNTAX OCTET STRING OCTET STRING is 0..65535 characters. Consider that a range of 0..255 would give 8*256 == 2048 Ports Are more ports needed? * Both compilers warn about rbridgeSnoopingEntry The DESCRIPTION clause indicates that IPv4 and IPv6 so 4 or 16 byes, so why is this not indicated? (An example is below.) rbridgeSnoopingAddrType OBJECT-TYPE SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2)} MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast address type for which a listener has been detected by this RBridge. This MIB requires support for only IPv4 and IPv6 address types." REFERENCE "RFC 6325 section 4.7" ::= { rbridgeSnoopingAddrEntry 1 } rbridgeSnoopingAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(0|4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast address for which a listener has been detected by this RBridge. The address type of this object is specified in rbridgeSnoopingAddrType. This MIB requires support for only global IPv4 and IPv6 addresses, so the length of the object can be either 4 or 16 bytes." REFERENCE "RFC 6325 section 4.7" ::= { rbridgeSnoopingAddrEntry 2 } * Suggested OID layout is not as Specified in the MIB Guidelines document: xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) Compliances and Groups are reversed in the MIB draft. INDEXING ======== I am a little concerned about the Indexing in this MIB, only because it looks like several table should really have an AUGMENTS relationship. INDEX { rbridgeBaseNicknameName } INDEX { rbridgeBasePort } INDEX { rbridgeFdbId, rbridgeUniFdbAddr } INDEX { rbridgeUniFibNickname, rbridgeUniFibPort, INDEX { rbridgeMultiFibNickname } INDEX { rbridgeVlanIndex } INDEX { rbridgeBasePort, rbridgeVlanIndex } INDEX { rbridgeBasePort } INDEX { rbridgeVlanIndex } INDEX { rbridgeBasePort } INDEX { rbridgeVlanIndex, rbridgeSnoopingAddrType, INDEX { rbridgeDtreeNumber } INDEX { rbridgeTrillNbrMacAddr } * Conformance Statement. Same comment as on the prior draft. Still no read-only and full conformance. This is okay, but want to make sure that working group is "okay" with having to do a full conformance (i.e. support read-write and read-create via SNMP)? ----- Original Message ----- From: "Bert Wijnen (IETF)" To: Cc: ; ; Sent: Tuesday, April 10, 2012 4:53 AM Subject: Re: [MIB-DOCTORS] Help with conformance statements > From a quick read that I did (section 6.7), then it > indeed seems to specify a set of requirements (even in > MUST) language for the ISIS-MIB module. So here (in > sect 6.7) they are described in English. > > It would indeed be useful to have that documented > in machine readable format, i.e. in (or as part of) > a MODULE-COMPLIANCE statement. > > Is it a reason to hold up the document? > Not sure about that. At the time when I was AD, I > tried to strongly encourage people to express such > requirements in the form of MODULE_COMPLIANCE > statements. But that was/is my view. > > Maybe other MIB doctors do have an opinion on that. > > Bert > > On 4/8/12 10:34 PM, Adrian Farrel wrote: >> Hi, >> >> Is there a MIB Doctor that can help us? >> >> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt >> >> It reads... >> >>> I would like help from the OPS ADs (and MIB Doctors) on this point: >>> >>> It seems to me that section 6.7 needs a new conformance statement to >>> be applied to ISIS-MIB. The text in the section appears to be in two >>> parts: >>> >>> - Implementation guidance (what value to return on a GET from a Trill >>> implementation) >>> >>> - Implementation requirements (which tables/objects to implement or >>> not (conformance statement). >> >> Can anyone tell me if I am right or wrong. >> >> Thanks, >> Adrian >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From glenn@cysols.com Tue Apr 10 23:29:57 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE8A21F86EB for ; Tue, 10 Apr 2012 23:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYpPwiiMtv3u for ; Tue, 10 Apr 2012 23:29:56 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1274721F8518 for ; Tue, 10 Apr 2012 23:29:55 -0700 (PDT) Received: from [192.168.0.193] (COOKIE.win2004.cysol.co.jp [192.168.0.193]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id q3B6TmJW044734 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 11 Apr 2012 15:29:49 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4F8524DC.8060307@cysols.com> Date: Wed, 11 Apr 2012 15:29:48 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mib-doctors@ietf.org References: <1408021768.1783695.1334067576269.JavaMail.root@zimbra-prod-mbox-2.vmware.com> In-Reply-To: <1408021768.1783695.1334067576269.JavaMail.root@zimbra-prod-mbox-2.vmware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] Fwd: Qestion about RFC 5676 and RFC 5427 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 06:29:57 -0000 Mike, The MIB document did spend a lot of time in the WG and several reviews and revisions. Some found it too simple and some found it too complex and some found it both.The WG ran out of steam on this document without arriving at any consensus. The MIB was dropped from the target in the revised charter of September 2009. As far as the Syslog-WG is concerned, the story ends there. I still think that the MIB is not all bad. (That makes two of us.) Waiting for someone to show some interest and take it further. I am ready to pitch in my bit. Cheers, Glenn (2012/04/10 23:19), Michael MacFaden wrote: > > What a shame the mib doesn't look half bad. > Oh well back to implementing proprietary managed objects to monitor it > like all the other vendors. > > > Thanks Juergen! > > Mike > > ----- Original Message ----- >> There was http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 >> but it never really took off - perhaps the attempt to model >> configuration objects given that some syslog implementations allow to >> do pretty wild things was a mistake. The data tracker history is >> here: >> >> https://datatracker.ietf.org/doc/draft-ietf-syslog-device-mib/history/ >> >> /js >> > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From mrm@vmware.com Tue Apr 10 21:03:12 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FC811E809F for ; Tue, 10 Apr 2012 21:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVQqaRWnwm3h for ; Tue, 10 Apr 2012 21:03:11 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id D638C11E8096 for ; Tue, 10 Apr 2012 21:03:11 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 169D928345 for ; Tue, 10 Apr 2012 21:03:11 -0700 (PDT) Received: from zimbra-prod-mta-1.vmware.com (zimbra-prod-mta-1.vmware.com [10.113.160.173]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 14C1DB0380 for ; Tue, 10 Apr 2012 21:03:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-prod-mta-1.vmware.com (Postfix) with ESMTP id 10D4FB154E for ; Tue, 10 Apr 2012 21:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra-prod-mta-1.vmware.com Received: from zimbra-prod-mta-1.vmware.com ([127.0.0.1]) by localhost (zimbra-prod-mta-1.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1YZ3T0V3mIK for ; Tue, 10 Apr 2012 21:03:11 -0700 (PDT) Received: from zimbra-prod-mbox-2.vmware.com (zimbra-prod-mbox-2.vmware.com [10.113.160.202]) by zimbra-prod-mta-1.vmware.com (Postfix) with ESMTP id F21C7B154D for ; Tue, 10 Apr 2012 21:03:10 -0700 (PDT) Date: Tue, 10 Apr 2012 21:03:10 -0700 (PDT) From: Michael MacFaden To: mib-doctors@ietf.org Message-ID: <706577667.1841210.1334116990873.JavaMail.root@zimbra-prod-mbox-2.vmware.com> In-Reply-To: <1233660844.1840209.1334115398270.JavaMail.root@zimbra-prod-mbox-2.vmware.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1841209_1269975595.1334116990872" X-Originating-IP: [10.113.60.13] X-Mailer: Zimbra 7.1.3_GA_3374 (ZimbraWebClient - GC18 (Mac)/7.1.3_GA_3346) X-Mailman-Approved-At: Wed, 11 Apr 2012 00:44:43 -0700 Subject: [MIB-DOCTORS] ISCSI-MIB technical review part 2 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:03:12 -0000 ------=_Part_1841209_1269975595.1334116990872 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Dan, Here are my notes of a review of the draft: draft-ietf-storm-iscsimib-01.txt http://macfaden.com/ietf/iscsi-mib-notes.txt Mike MacFaden ------=_Part_1841209_1269975595.1334116990872 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: tahoma, new york, times, serif; font-size: 12pt; = color: #000000'>
Hi Dan,
 
http://macfaden.com/ietf/iscsi-mib-notes.txt<= /div>

Mike MacFaden


------=_Part_1841209_1269975595.1334116990872-- From adrian@olddog.co.uk Fri Apr 13 09:35:04 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8121F8802 for ; Fri, 13 Apr 2012 09:35:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlhpWGLvGG1I for ; Fri, 13 Apr 2012 09:35:02 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id A3C4621F87F7 for ; Fri, 13 Apr 2012 09:34:51 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3DGYn2K007865; Fri, 13 Apr 2012 17:34:49 +0100 Received: from 950129200 (AGrenoble-551-1-13-42.w92-133.abo.wanadoo.fr [92.133.244.42]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3DGYLgM007667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Apr 2012 17:34:45 +0100 From: "Adrian Farrel" To: "'Anil Rijhsinghani'" Date: Fri, 13 Apr 2012 17:34:17 +0100 Message-ID: <01e101cd1993$5779f630$066de290$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0Zjs+VeWMwgsNfRQSbW8hLfVvz+w== Content-Language: en-gb Cc: mib-doctors@ietf.org, draft-ietf-trill-rbridge-mib@tools.ietf.org, ops-ads@tools.ietf.org, int-ads@tools.ietf.org Subject: Re: [MIB-DOCTORS] Help with conformance statements in draft-ietf-trill-rbridge-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:35:04 -0000 Anil, The Ops ADs and your own ADs [added to this message] will probably have = a view on this. My feeling is that a Trill implementation is somewhat = dependent on an IS-IS implementation. Therefore the MIB module for an = Rbridge is not complete without the ability to model/manage an IS-IS = speaker.=20 It is possible that you can cover this with suitable wording, however, = it remains my opinion that the correct way to handle this is with a = compliance statement. I have two reasons for saying this: 1. An Rbridge is not properly manageable without IS-IS management 2. The IS-IS module is not fully applicable to an Rbridge Cheers, Adrian > -----Original Message----- > From: Anil Rijhsinghani [mailto:anil@charter.net] > Sent: 10 April 2012 17:38 > To: Bert Wijnen (IETF) > Cc: adrian@olddog.co.uk; ops-ads@tools.ietf.org; mib-doctors@ietf.org; = draft- > ietf-trill-rbridge-mib@tools.ietf.org > Subject: Re: [MIB-DOCTORS] Help with conformance statements >=20 > Agreed that the MUST etc language is unusual for a "Relationships to > other MIBs" section. I haven't looked at this section in a while. = There > are references to several other MIBs as well in that part of the > document, and the description in those is not at the level of 6.7, nor > should it be. >=20 > Let me go back and edit that section to bring it more in line with > other "Relationship" sections in the draft, and see if it becomes more > acceptable. >=20 > I'd rather not add new Compliance clauses for other MIBs as that would > be enforced in syntax and will have to go back to at least the RBridge > WG (and perhaps even the IS-IS WG) for agreement - which will almost > certainly take several months more. The intention was not to enforce > this stuff, only to provide hints to implementors, and many of these > hints are probably overkill. >=20 > I'll work on that section and submit another draft by end of week. >=20 > Regards, > Anil >=20 >=20 > On Tue, Apr 10, 2012 at 4:53 AM, Bert Wijnen (IETF) wrote: >=20 > > From a quick read that I did (section 6.7), then it > > indeed seems to specify a set of requirements (even in > > MUST) language for the ISIS-MIB module. So here (in > > sect 6.7) they are described in English. > > > > It would indeed be useful to have that documented > > in machine readable format, i.e. in (or as part of) > > a MODULE-COMPLIANCE statement. > > > > Is it a reason to hold up the document? > > Not sure about that. At the time when I was AD, I > > tried to strongly encourage people to express such > > requirements in the form of MODULE_COMPLIANCE > > statements. But that was/is my view. > > > > Maybe other MIB doctors do have an opinion on that. > > > > Bert > > > > On 4/8/12 10:34 PM, Adrian Farrel wrote: > >> Hi, > >> > >> Is there a MIB Doctor that can help us? > >> > >> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt > >> > >> It reads... > >> > >>> I would like help from the OPS ADs (and MIB Doctors) on this = point: > >>> > >>> It seems to me that section 6.7 needs a new conformance statement = to > >>> be applied to ISIS-MIB. The text in the section appears to be in = two > >>> parts: > >>> > >>> - Implementation guidance (what value to return on a GET from a > >>> Trill > >>> implementation) > >>> > >>> - Implementation requirements (which tables/objects to implement = or > >>> not (conformance statement). > >> > >> Can anyone tell me if I am right or wrong. > >> > >> Thanks, > >> Adrian > >> > >> > >> _______________________________________________ > >> MIB-DOCTORS mailing list > >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mib-doctors > >> From andy@netconfcentral.org Fri Apr 13 09:50:12 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1E311E8075 for ; Fri, 13 Apr 2012 09:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhwZxZ-LXER7 for ; Fri, 13 Apr 2012 09:50:11 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 04CD721F8577 for ; Fri, 13 Apr 2012 09:50:07 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3DGo79e012429 for ; Fri, 13 Apr 2012 12:50:07 -0400 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43958] helo=[192.168.0.9]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3B/EB-23914-E39588F4; Fri, 13 Apr 2012 12:50:07 -0400 Message-ID: <4F885945.3070008@netconfcentral.org> Date: Fri, 13 Apr 2012 09:50:13 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <01e101cd1993$5779f630$066de290$@olddog.co.uk> In-Reply-To: <01e101cd1993$5779f630$066de290$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mib-doctors@ietf.org, draft-ietf-trill-rbridge-mib@tools.ietf.org, 'Anil Rijhsinghani' , int-ads@tools.ietf.org, ops-ads@tools.ietf.org Subject: Re: [MIB-DOCTORS] Help with conformance statements in draft-ietf-trill-rbridge-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:50:12 -0000 On 04/13/2012 09:34 AM, Adrian Farrel wrote: > Anil, > > The Ops ADs and your own ADs [added to this message] will probably have a view on this. My feeling is that a Trill implementation is somewhat dependent on an IS-IS implementation. Therefore the MIB module for an Rbridge is not complete without the ability to model/manage an IS-IS speaker. > > It is possible that you can cover this with suitable wording, however, it remains my opinion that the correct way to handle this is with a compliance statement. I have two reasons for saying this: > 1. An Rbridge is not properly manageable without IS-IS management > 2. The IS-IS module is not fully applicable to an Rbridge > I agree that a MODULE-COMPLIANCE macro is the correct solution. Your WG needs to agree on the specific objects from the specific MIB modules that need to be supported. > Cheers, > Adrian Andy > >> -----Original Message----- >> From: Anil Rijhsinghani [mailto:anil@charter.net] >> Sent: 10 April 2012 17:38 >> To: Bert Wijnen (IETF) >> Cc: adrian@olddog.co.uk; ops-ads@tools.ietf.org; mib-doctors@ietf.org; draft- >> ietf-trill-rbridge-mib@tools.ietf.org >> Subject: Re: [MIB-DOCTORS] Help with conformance statements >> >> Agreed that the MUST etc language is unusual for a "Relationships to >> other MIBs" section. I haven't looked at this section in a while. There >> are references to several other MIBs as well in that part of the >> document, and the description in those is not at the level of 6.7, nor >> should it be. >> >> Let me go back and edit that section to bring it more in line with >> other "Relationship" sections in the draft, and see if it becomes more >> acceptable. >> >> I'd rather not add new Compliance clauses for other MIBs as that would >> be enforced in syntax and will have to go back to at least the RBridge >> WG (and perhaps even the IS-IS WG) for agreement - which will almost >> certainly take several months more. The intention was not to enforce >> this stuff, only to provide hints to implementors, and many of these >> hints are probably overkill. >> >> I'll work on that section and submit another draft by end of week. >> >> Regards, >> Anil >> >> >> On Tue, Apr 10, 2012 at 4:53 AM, Bert Wijnen (IETF) wrote: >> >>> From a quick read that I did (section 6.7), then it >>> indeed seems to specify a set of requirements (even in >>> MUST) language for the ISIS-MIB module. So here (in >>> sect 6.7) they are described in English. >>> >>> It would indeed be useful to have that documented >>> in machine readable format, i.e. in (or as part of) >>> a MODULE-COMPLIANCE statement. >>> >>> Is it a reason to hold up the document? >>> Not sure about that. At the time when I was AD, I >>> tried to strongly encourage people to express such >>> requirements in the form of MODULE_COMPLIANCE >>> statements. But that was/is my view. >>> >>> Maybe other MIB doctors do have an opinion on that. >>> >>> Bert >>> >>> On 4/8/12 10:34 PM, Adrian Farrel wrote: >>>> Hi, >>>> >>>> Is there a MIB Doctor that can help us? >>>> >>>> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt >>>> >>>> It reads... >>>> >>>>> I would like help from the OPS ADs (and MIB Doctors) on this point: >>>>> >>>>> It seems to me that section 6.7 needs a new conformance statement to >>>>> be applied to ISIS-MIB. The text in the section appears to be in two >>>>> parts: >>>>> >>>>> - Implementation guidance (what value to return on a GET from a >>>>> Trill >>>>> implementation) >>>>> >>>>> - Implementation requirements (which tables/objects to implement or >>>>> not (conformance statement). >>>> >>>> Can anyone tell me if I am right or wrong. >>>> >>>> Thanks, >>>> Adrian >>>> >>>> >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>> > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > From dromasca@avaya.com Sun Apr 15 07:04:07 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E21221F87AE for ; Sun, 15 Apr 2012 07:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFBvE5mvweSn for ; Sun, 15 Apr 2012 07:04:06 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3421F8797 for ; Sun, 15 Apr 2012 07:04:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIPAM7Tik/GmAcF/2dsb2JhbAA9Bq1xhxmBB4IJAQEBAQMBAQEPHgo0BAcMBAIBCA0EBAEBAQoGDAsBBgEmHwkIAQEEARIIEweHbAubc5ttBItBhSVjBJwBiiGCaQ X-IronPort-AV: E=Sophos;i="4.75,425,1330923600"; d="scan'208";a="4413606" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 15 Apr 2012 10:04:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Apr 2012 10:02:03 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Apr 2012 16:03:59 +0200 Message-ID: In-Reply-To: <4F885945.3070008@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] Help with conformance statements indraft-ietf-trill-rbridge-mib Thread-Index: Ac0ZlYDir7wuNHK9RQmLcCkKQ5UXQABesfYg References: <01e101cd1993$5779f630$066de290$@olddog.co.uk> <4F885945.3070008@netconfcentral.org> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , Cc: mib-doctors@ietf.org, ops-ads@tools.ietf.org, draft-ietf-trill-rbridge-mib@tools.ietf.org, Anil Rijhsinghani , int-ads@tools.ietf.org Subject: Re: [MIB-DOCTORS] Help with conformance statements indraft-ietf-trill-rbridge-mib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 14:04:07 -0000 I agree with Andy. If only part of the IS-IS MIB module applies to Rbridges, than the MODULE-COMPLIANCE statement can specify which objects or MIB groups need to be supported.=20 Regards, Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- > bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Friday, April 13, 2012 7:50 PM > To: adrian@olddog.co.uk > Cc: mib-doctors@ietf.org; draft-ietf-trill-rbridge-mib@tools.ietf.org; > 'Anil Rijhsinghani'; int-ads@tools.ietf.org; ops-ads@tools.ietf.org > Subject: Re: [MIB-DOCTORS] Help with conformance statements indraft- > ietf-trill-rbridge-mib >=20 > On 04/13/2012 09:34 AM, Adrian Farrel wrote: > > Anil, > > > > The Ops ADs and your own ADs [added to this message] will probably > have a view on this. My feeling is that a Trill implementation is > somewhat dependent on an IS-IS implementation. Therefore the MIB module > for an Rbridge is not complete without the ability to model/manage an > IS-IS speaker. > > > > It is possible that you can cover this with suitable wording, > however, it remains my opinion that the correct way to handle this is > with a compliance statement. I have two reasons for saying this: > > 1. An Rbridge is not properly manageable without IS-IS management > > 2. The IS-IS module is not fully applicable to an Rbridge > > >=20 >=20 > I agree that a MODULE-COMPLIANCE macro is the correct solution. > Your WG needs to agree on the specific objects from the specific MIB > modules > that need to be supported. >=20 > > Cheers, > > Adrian >=20 > Andy >=20 >=20 > > > >> -----Original Message----- > >> From: Anil Rijhsinghani [mailto:anil@charter.net] > >> Sent: 10 April 2012 17:38 > >> To: Bert Wijnen (IETF) > >> Cc: adrian@olddog.co.uk; ops-ads@tools.ietf.org; mib- > doctors@ietf.org; draft- > >> ietf-trill-rbridge-mib@tools.ietf.org > >> Subject: Re: [MIB-DOCTORS] Help with conformance statements > >> > >> Agreed that the MUST etc language is unusual for a "Relationships to > >> other MIBs" section. I haven't looked at this section in a while. > There > >> are references to several other MIBs as well in that part of the > >> document, and the description in those is not at the level of 6.7, > nor > >> should it be. > >> > >> Let me go back and edit that section to bring it more in line with > >> other "Relationship" sections in the draft, and see if it becomes > more > >> acceptable. > >> > >> I'd rather not add new Compliance clauses for other MIBs as that > would > >> be enforced in syntax and will have to go back to at least the > RBridge > >> WG (and perhaps even the IS-IS WG) for agreement - which will almost > >> certainly take several months more. The intention was not to enforce > >> this stuff, only to provide hints to implementors, and many of these > >> hints are probably overkill. > >> > >> I'll work on that section and submit another draft by end of week. > >> > >> Regards, > >> Anil > >> > >> > >> On Tue, Apr 10, 2012 at 4:53 AM, Bert Wijnen (IETF) wrote: > >> > >>> From a quick read that I did (section 6.7), then it > >>> indeed seems to specify a set of requirements (even in > >>> MUST) language for the ISIS-MIB module. So here (in > >>> sect 6.7) they are described in English. > >>> > >>> It would indeed be useful to have that documented > >>> in machine readable format, i.e. in (or as part of) > >>> a MODULE-COMPLIANCE statement. > >>> > >>> Is it a reason to hold up the document? > >>> Not sure about that. At the time when I was AD, I > >>> tried to strongly encourage people to express such > >>> requirements in the form of MODULE_COMPLIANCE > >>> statements. But that was/is my view. > >>> > >>> Maybe other MIB doctors do have an opinion on that. > >>> > >>> Bert > >>> > >>> On 4/8/12 10:34 PM, Adrian Farrel wrote: > >>>> Hi, > >>>> > >>>> Is there a MIB Doctor that can help us? > >>>> > >>>> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt > >>>> > >>>> It reads... > >>>> > >>>>> I would like help from the OPS ADs (and MIB Doctors) on this > point: > >>>>> > >>>>> It seems to me that section 6.7 needs a new conformance statement > to > >>>>> be applied to ISIS-MIB. The text in the section appears to be in > two > >>>>> parts: > >>>>> > >>>>> - Implementation guidance (what value to return on a GET from a > >>>>> Trill > >>>>> implementation) > >>>>> > >>>>> - Implementation requirements (which tables/objects to implement > or > >>>>> not (conformance statement). > >>>> > >>>> Can anyone tell me if I am right or wrong. > >>>> > >>>> Thanks, > >>>> Adrian > >>>> > >>>> > >>>> _______________________________________________ > >>>> MIB-DOCTORS mailing list > >>>> MIB-DOCTORS@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mib-doctors > >>>> > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > > > >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Mon Apr 16 02:01:01 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85BA21F8734; Mon, 16 Apr 2012 02:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35iiad5mj1Do; Mon, 16 Apr 2012 02:01:01 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D684421F86E3; Mon, 16 Apr 2012 02:01:00 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3G90uYI025303; Mon, 16 Apr 2012 11:00:56 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3G90tFs008749; Mon, 16 Apr 2012 11:00:55 +0200 (CEST) Message-ID: <4F8BDFC7.3040703@cisco.com> Date: Mon, 16 Apr 2012 11:00:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:01:01 -0000 Hi Dan, The most important reason to have an ENTITY-MIB v4 is the addition of a proper read-only UUID, as opposed to using the entPhysicalUris, or even defining an EMAN specific UUID. So I support this work. Regards, Benoit (as a contributor) > Hi MIB Doctors, > > I am not sure how many of you follow the EMAN WG which has a chartered > item for a Power and Energy Monitoring MIB - > http://www.ietf.org/id/draft-ietf-eman-energy-monitoring-mib-02.txt. One > of the issue they are encountering is the need to support a small subset > of objects from the Entity MIB composed of entPhysicalIndex, > entPhysicalName and entPhysicalUris (which in their case is read-only > and limited size). Full support of the Entity MIB as per RFC 4133 may > happen but they estimate it would be an extra-load for the devices > reporting power and energy information. A proposal was made to define > the subset of objects they need as a module compliance for small energy > reporting devices to be defined for the Entity MIB (see slides 8 and 9 > in http://www.ietf.org/proceedings/83/slides/slides-83-eman-3.pdf). > > My question is whether you see such a solution causing any problem? > Is it worth a v4 for the Entity MIB, or could it be done differently? > > Thanks and Regards, > > Dan > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > From moulchan@cisco.com Thu Apr 19 01:36:09 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5978E21F85D9; Thu, 19 Apr 2012 01:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfpToF21+EVo; Thu, 19 Apr 2012 01:36:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA5521F85B4; Thu, 19 Apr 2012 01:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1818; q=dns/txt; s=iport; t=1334824565; x=1336034165; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+ZlzetIAHxc60iBUTI0iwp7PzQWrlmWBarn7gC3CvCk=; b=g//GnnD2+RHh0NFsmLRKOO+4FLIyngkW5wJwcjuj8DqHTX4LKUAMXEAv rKUa6Ju1LltLY4XFKNabzaqq9Bnq424O404h2xb+ftrTEV9YiWATeCxTO KmwtBsJ2uHqk41Cx6BGng4bxVZncThq4W54UlTBqJKxks6riogLE39KyO k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOvNj0+tJXG8/2dsb2JhbABDsUqBB4IJAQEBAgIBAQEPAR0KNAsMBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIARIHh20LmjCgN4pkhG5jBIhcm2SBaYMFgTY X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="75972786" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 19 Apr 2012 08:36:04 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q3J8VUPw014234; Thu, 19 Apr 2012 08:35:24 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 03:35:08 -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: Thu, 19 Apr 2012 03:35:05 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0SclCuvMhGdm48QlyBzsYXEyxfkgLlCevQ References: From: "Mouli Chandramouli (moulchan)" To: "Romascanu, Dan (Dan)" , "MIB Doctors" X-OriginalArrivalTime: 19 Apr 2012 08:35:08.0813 (UTC) FILETIME=[5418D3D0:01CD1E07] X-Mailman-Approved-At: Thu, 19 Apr 2012 01:41:22 -0700 Cc: eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 08:36:09 -0000 Thanks Dan.=20 As you have suggested some of the desirable features for ENTITY MIB V4 from an EMAN point of view shall be=20 - entPhysicalClass to be an IANA controlled list =20 - is it possible to have a smaller set of ENTITY MIB objects for possible compliance with ENTITY-MIB=20 - entPhysicalUris to be read-only object=20 - representation of UUID compliant with rfc 4122 ?=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, April 04, 2012 8:21 PM To: MIB Doctors Cc: eman@ietf.org Subject: [eman] Entity MIBv4? Hi MIB Doctors, I am not sure how many of you follow the EMAN WG which has a chartered item for a Power and Energy Monitoring MIB - http://www.ietf.org/id/draft-ietf-eman-energy-monitoring-mib-02.txt. One of the issue they are encountering is the need to support a small subset of objects from the Entity MIB composed of entPhysicalIndex, entPhysicalName and entPhysicalUris (which in their case is read-only and limited size). Full support of the Entity MIB as per RFC 4133 may happen but they estimate it would be an extra-load for the devices reporting power and energy information. A proposal was made to define the subset of objects they need as a module compliance for small energy reporting devices to be defined for the Entity MIB (see slides 8 and 9 in http://www.ietf.org/proceedings/83/slides/slides-83-eman-3.pdf).=20 My question is whether you see such a solution causing any problem?=20 Is it worth a v4 for the Entity MIB, or could it be done differently?=20 Thanks and Regards, Dan _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Thu Apr 19 01:54:14 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801D321F85A3; Thu, 19 Apr 2012 01:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nxAbvj0g9aU; Thu, 19 Apr 2012 01:54:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 619E421F85D7; Thu, 19 Apr 2012 01:54:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78D1120C8A; Thu, 19 Apr 2012 10:54:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6XsRzf-sgZnG; Thu, 19 Apr 2012 10:54:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18BAE20C7D; Thu, 19 Apr 2012 10:54:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0E7BE1E6BD66; Thu, 19 Apr 2012 10:54:06 +0200 (CEST) Date: Thu, 19 Apr 2012 10:54:06 +0200 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20120419085405.GB61803@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "Romascanu, Dan (Dan)" , MIB Doctors , eman@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.21 (2010-09-15) Cc: eman@ietf.org, MIB Doctors Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 08:54:15 -0000 On Thu, Apr 19, 2012 at 03:35:05AM -0500, Mouli Chandramouli (moulchan) wrote: > Thanks Dan. > > As you have suggested some of the desirable features for ENTITY MIB V4 > from an EMAN point of view shall be > > - entPhysicalClass to be an IANA controlled list > - is it possible to have a smaller set of ENTITY MIB objects for > possible compliance with ENTITY-MIB You can have an additional conformance statement and compliance is to a conformance statement not the ENTITY-MIB. > - entPhysicalUris to be read-only object That won't happen; you can have a complaince statement that does not require writable implementation. > - representation of UUID compliant with rfc 4122 ? Not 100% sure what this means. entPhysicalUris can contain an RFC 4122 UUID URN. Perhaps you are asking for a separate entPhysicalUuid object. If so, I am not sure you need the extra URN verbosity. /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 Thu Apr 19 02:02:30 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8721F84E1; Thu, 19 Apr 2012 02:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.443 X-Spam-Level: X-Spam-Status: No, score=-103.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7k0PM4R6r7i; Thu, 19 Apr 2012 02:02:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id CFB7521F84DF; Thu, 19 Apr 2012 02:02:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF3Uj0+HCzI1/2dsb2JhbABDsUmBB4IJAQEBAQMSHgo/DAQCAQgNAQIBBAEBAQoGDAsBBgFFCQgBAQQBEggah22dJJ1Ej1JjBJcAhQSKJYJp X-IronPort-AV: E=Sophos;i="4.75,445,1330923600"; d="scan'208";a="343185283" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Apr 2012 05:01:58 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Apr 2012 04:45:42 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Apr 2012 11:02:15 +0200 Message-ID: In-Reply-To: <20120419085405.GB61803@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eCgGSIGUtSa7YSUqT/J9KkseGFwAAB0oQ References: <20120419085405.GB61803@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Mouli Chandramouli (moulchan)" Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 09:02:30 -0000 See in-line.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, April 19, 2012 11:54 AM > To: Mouli Chandramouli (moulchan) > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: Re: [eman] Entity MIBv4? >=20 > On Thu, Apr 19, 2012 at 03:35:05AM -0500, Mouli Chandramouli (moulchan) > wrote: > > Thanks Dan. > > > > As you have suggested some of the desirable features for ENTITY MIB > V4 > > from an EMAN point of view shall be > > > > - entPhysicalClass to be an IANA controlled list > > - is it possible to have a smaller set of ENTITY MIB objects for > > possible compliance with ENTITY-MIB >=20 > You can have an additional conformance statement and compliance is > to a conformance statement not the ENTITY-MIB. [[DR]] Exactly. >=20 > > - entPhysicalUris to be read-only object >=20 > That won't happen; you can have a complaince statement that does not > require writable implementation. >=20 [[DR]] Of course. Other classes of entities will use the compliance statement(s) that requires read-write access > > - representation of UUID compliant with rfc 4122 ? >=20 > Not 100% sure what this means. entPhysicalUris can contain an RFC 4122 > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > object. If so, I am not sure you need the extra URN verbosity. >=20 [[DR]] This is the only issue that seems open in my view - meaning the slides and discussions at the meeting did not seem to lead to a conclusion. Do we expect cases where both a RFC 4122 compliant UUID representation and also another entPhysicalUri format will be needed? Dan =20 > /js >=20 From dromasca@avaya.com Thu Apr 19 02:51:54 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8987221F8593; Thu, 19 Apr 2012 02:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.952 X-Spam-Level: X-Spam-Status: No, score=-102.952 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoSL1wEBBfcX; Thu, 19 Apr 2012 02:51:47 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 40BE721F8573; Thu, 19 Apr 2012 02:51:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALrfj0+HCzI1/2dsb2JhbABDsT+BB4IJAQEBAQMSHgo0CwwEAgEIDQMBBAEBAQoGDAsBBgFFCQgBAQQBEggBGYdtC50VnUWKcYRpYwSXAYUEiiWCaYFa X-IronPort-AV: E=Sophos;i="4.75,446,1330923600"; d="scan'208";a="5124569" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Apr 2012 05:51:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Apr 2012 05:35:07 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Apr 2012 11:51:40 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eCgGSIGUtSa7YSUqT/J9KkseGFwAAB0oQAAEb8pAAAKWscA== References: <20120419085405.GB61803@elstar.local> From: "Romascanu, Dan (Dan)" To: "Mouli Chandramouli (moulchan)" , "Juergen Schoenwaelder" Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 09:51:54 -0000 Hi, See in-line.=20 Regards, Dan > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Thursday, April 19, 2012 12:42 PM > To: Romascanu, Dan (Dan); Juergen Schoenwaelder > Cc: MIB Doctors; eman@ietf.org > Subject: RE: [eman] Entity MIBv4? >=20 > Thanks. Replies inline. >=20 > Mouli >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, April 19, 2012 2:32 PM > To: Juergen Schoenwaelder; Mouli Chandramouli (moulchan) > Cc: MIB Doctors; eman@ietf.org > Subject: RE: [eman] Entity MIBv4? >=20 > See in-line. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Thursday, April 19, 2012 11:54 AM > > To: Mouli Chandramouli (moulchan) > > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > > Subject: Re: [eman] Entity MIBv4? > > > > On Thu, Apr 19, 2012 at 03:35:05AM -0500, Mouli Chandramouli > (moulchan) > > wrote: > > > Thanks Dan. > > > > > > As you have suggested some of the desirable features for ENTITY MIB > > V4 > > > from an EMAN point of view shall be > > > > > > - entPhysicalClass to be an IANA controlled list > > > - is it possible to have a smaller set of ENTITY MIB objects for > > > possible compliance with ENTITY-MIB > > > > You can have an additional conformance statement and compliance is > > to a conformance statement not the ENTITY-MIB. >=20 >=20 > [[DR]] Exactly. > [ycm] OK. A clarification from a novice. Those conformance statements > should included in the ENTITY-MIB conformance section ? >=20 [[DR]] Yes, they are added to the existing conformance clauses.=20 > > > > > - entPhysicalUris to be read-only object > > > > That won't happen; you can have a complaince statement that does not > > require writable implementation. > > >=20 > [[DR]] Of course. Other classes of entities will use the compliance > statement(s) that requires read-write access > [ycm] OK >=20 >=20 >=20 > > > - representation of UUID compliant with rfc 4122 ? > > > > Not 100% sure what this means. entPhysicalUris can contain an RFC > 4122 > > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > > object. If so, I am not sure you need the extra URN verbosity. > > > [[DR]] This is the only issue that seems open in my view - meaning the > slides and discussions at the meeting did not seem to lead to a > conclusion. Do we expect cases where both a RFC 4122 compliant UUID > representation and also another entPhysicalUri format will be needed? >=20 > [ycm] Two possible approaches for UUID representation as given in the > mailing list and slides > [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html >=20 >=20 > [[DR]] So, are you arguing that there is a need for a separate object?=20 From moulchan@cisco.com Thu Apr 19 02:42:20 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6C21F8559; Thu, 19 Apr 2012 02:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzqSn2PGHfHY; Thu, 19 Apr 2012 02:42:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9F921F85BB; Thu, 19 Apr 2012 02:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2392; q=dns/txt; s=iport; t=1334828535; x=1336038135; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tfOwUx+n3w4jQxlUFxV/wkCiznUCAcoT7hwGurDFyXI=; b=QdGA1jC4C1J+GPQE3jRCSHXqe74bUjcGNjCUyZqsWmkHSD3bVdHN14+E j7eTlUMWbU2jmWkQK1Y87j2cRRQBvZue3jfpVbhTIPWY3F0g4nOQ8Uf6g lRX8OMAyabZVr1npCl+g9b5s6AOzFCwAjLe7YbuotnBUsym0pPTDAexzn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG/dj0+tJV2a/2dsb2JhbABDsT+BB4IJAQEBBBIBHQo0CwwEAgEIEAEEAQEBCgYXAQYBRQkIAQEEARIIARmHbQuaK6A3inGEaWMEiFyOJY1AgWmDBYE+ X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="76001795" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 19 Apr 2012 09:42:15 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3J9gEkc003341; Thu, 19 Apr 2012 09:42:15 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 04:42:14 -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: Thu, 19 Apr 2012 04:42:11 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eCgGSIGUtSa7YSUqT/J9KkseGFwAAB0oQAAEb8pA= References: <20120419085405.GB61803@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Romascanu, Dan (Dan)" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 19 Apr 2012 09:42:14.0889 (UTC) FILETIME=[B3D34590:01CD1E10] X-Mailman-Approved-At: Thu, 19 Apr 2012 02:56:54 -0700 Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 09:42:20 -0000 Thanks. Replies inline.=20 Mouli -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Thursday, April 19, 2012 2:32 PM To: Juergen Schoenwaelder; Mouli Chandramouli (moulchan) Cc: MIB Doctors; eman@ietf.org Subject: RE: [eman] Entity MIBv4? See in-line.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, April 19, 2012 11:54 AM > To: Mouli Chandramouli (moulchan) > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: Re: [eman] Entity MIBv4? >=20 > On Thu, Apr 19, 2012 at 03:35:05AM -0500, Mouli Chandramouli (moulchan) > wrote: > > Thanks Dan. > > > > As you have suggested some of the desirable features for ENTITY MIB > V4 > > from an EMAN point of view shall be > > > > - entPhysicalClass to be an IANA controlled list > > - is it possible to have a smaller set of ENTITY MIB objects for > > possible compliance with ENTITY-MIB >=20 > You can have an additional conformance statement and compliance is > to a conformance statement not the ENTITY-MIB. [[DR]] Exactly. [ycm] OK. A clarification from a novice. Those conformance statements should included in the ENTITY-MIB conformance section ?=20 >=20 > > - entPhysicalUris to be read-only object >=20 > That won't happen; you can have a complaince statement that does not > require writable implementation. >=20 [[DR]] Of course. Other classes of entities will use the compliance statement(s) that requires read-write access [ycm] OK > > - representation of UUID compliant with rfc 4122 ? >=20 > Not 100% sure what this means. entPhysicalUris can contain an RFC 4122 > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > object. If so, I am not sure you need the extra URN verbosity. >=20 [[DR]] This is the only issue that seems open in my view - meaning the slides and discussions at the meeting did not seem to lead to a conclusion. Do we expect cases where both a RFC 4122 compliant UUID representation and also another entPhysicalUri format will be needed? [ycm] Two possible approaches for UUID representation as given in the mailing list and slides=20 [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html Dan =20 > /js >=20 From j.schoenwaelder@jacobs-university.de Thu Apr 19 03:26:42 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B25D21F85B9; Thu, 19 Apr 2012 03:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.167 X-Spam-Level: X-Spam-Status: No, score=-103.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB8HZR0uK1fU; Thu, 19 Apr 2012 03:26:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8303C21F84B6; Thu, 19 Apr 2012 03:26:37 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D566F20CC8; Thu, 19 Apr 2012 12:26:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n5-zOCexRlie; Thu, 19 Apr 2012 12:26:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B14E20C59; Thu, 19 Apr 2012 12:26:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 10FAF1E6C1A3; Thu, 19 Apr 2012 12:26:36 +0200 (CEST) Date: Thu, 19 Apr 2012 12:26:36 +0200 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20120419102636.GA62360@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "Romascanu, Dan (Dan)" , MIB Doctors , eman@ietf.org References: <20120419085405.GB61803@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org, MIB Doctors Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 10:26:42 -0000 On Thu, Apr 19, 2012 at 04:42:11AM -0500, Mouli Chandramouli (moulchan) wrote: > > > - representation of UUID compliant with rfc 4122 ? > > > > Not 100% sure what this means. entPhysicalUris can contain an RFC 4122 > > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > > object. If so, I am not sure you need the extra URN verbosity. > > > [[DR]] This is the only issue that seems open in my view - meaning the > slides and discussions at the meeting did not seem to lead to a > conclusion. Do we expect cases where both a RFC 4122 compliant UUID > representation and also another entPhysicalUri format will be needed? > > [ycm] Two possible approaches for UUID representation as given in the > mailing list and slides > [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html The question is whether it is wise to encode a UUID, which is essentially 16 binary octets, in a representation that requires 45 octets. I am pretty optimistic that a DISPLAY-HINT definition can be provided that renders 16 binary octets into something like "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Fri Apr 20 02:11:40 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C2021F879B; Fri, 20 Apr 2012 02:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-kf8IhWcmH7; Fri, 20 Apr 2012 02:11:39 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 30B2521F8763; Fri, 20 Apr 2012 02:11:39 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3K9Bbkg025422; Fri, 20 Apr 2012 11:11:37 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3K9BaEb020693; Fri, 20 Apr 2012 11:11:36 +0200 (CEST) Message-ID: <4F912848.8070704@cisco.com> Date: Fri, 20 Apr 2012 11:11:36 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: aaa-doctors@ietf.org, "MIB Doctors (E-mail)" , YANG Doctors , ops-dir@ietf.org, IETF DNS Directorate References: <20120419220212.6285.20839.idtracker@ietfa.amsl.com> In-Reply-To: <20120419220212.6285.20839.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120419220212.6285.20839.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Summarized Agenda for the 2012-04-26 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 09:11:40 -0000 Dear all, Please find below the agenda of the April 26th IESG telechat. Please send your questions, comments and concerns before April 25th COB. Thanks and Regards, Benoit. -------- Original Message -------- INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2012-04-26 IESG Teleconference This agenda was generated at 2012-04-19 15:00:35 PDT Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-geopriv-policy-25 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information (Proposed Standard) Note: The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com). Token: Robert Sparks o draft-ietf-kitten-gssapi-naming-exts-14 GSS-API Naming Extensions (Proposed Standard) Note: Shawn Emery (shawn.emery@oracle.com) is the document shepherd. Token: Stephen Farrell o draft-ietf-ipfix-psamp-mib-04 Definitions of Managed Objects for Packet Sampling (Proposed Standard) Note: Nevil Brownlee is the document shepherd Token: Ronald Bonica o draft-ietf-marf-as-13 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) (Proposed Standard) Note: Barry Leiba (barryleiba@computer.org) is the document shepherd. Token: Pete Resnick o draft-ietf-dhc-dhcpv6-redundancy-consider-02 DHCPv6 Redundancy Deployment Considerations (Best Current Practice) Note: Ted Lemon (ted.lemon@nominum.com) is the document shepherd. Token: Ralph Droms o draft-ietf-emu-chbind-14 Channel Binding Support for EAP Methods (Proposed Standard) Note: Joe Salowey (jsalowey@cisco.com), EMU working group co-chair, is the Working Group Shepherd for this document. Token: Sean Turner o draft-ietf-appsawg-greylisting-07 Email Greylisting: An Applicability Statement for SMTP (Proposed Standard) Token: Barry Leiba o draft-ietf-sipcore-rfc3265bis-08 SIP-Specific Event Notification (Proposed Standard) Note: Paul Kyzivat (pkyzivat@alum.mit.edu) is the document shepherd. Token: Robert Sparks o draft-ietf-krb-wg-des-die-die-die-04 Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos (Best Current Practice) Note: Sam Hartman (hartmans-ietf@mit.edu) is the document shepherd. Token: Stephen Farrell 2.1.2 Returning Items o draft-ietf-fecframe-raptor-10 Raptor FEC Schemes for FECFRAME (Proposed Standard) Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd. Token: Martin Stiemerling o draft-ietf-appsawg-xdash-05 Deprecating the X- Prefix and Similar Constructs in Application Protocols (Best Current Practice) Token: Pete Resnick 2.2 Individual Submissions 2.2.1 New Items o draft-dbider-sha2-mac-for-ssh-05 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol (Proposed Standard) Note: Jeffrey Hutzelman (jhutz@cmu.edu) is the document shepherd. Token: Sean Turner 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-ecrit-lost-sync-17 Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements (Experimental) Note: Marc Linsner (mlinsner@cisco.com) is the document shepherd. Token: Robert Sparks o draft-ietf-pkix-pubkey-caps-04 S/MIME Capabilities for Public Key Definitions (Informational) Note: Document Shepherd: Stephen Kent (kent@bbn.com) Token: Sean Turner 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-templin-aero-10 Asymmetric Extended Route Optimization (AERO) (Informational) Token: Stewart Bryant 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.3.3 For Action o draft-irtf-dtnrg-prophet-09 Probabilistic Routing Protocol for Intermittently Connected Networks (Experimental) Note: IRTF Submission. Stephen Farrell (stephen.farrell@cs.tcd.ie) is the document shepherd. Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o sunset4 (sunset4) Token: Ralph Droms o Network Virtualization Overlays (nvo3) Token: Stewart Bryant 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From bclaise@cisco.com Wed Apr 25 15:40:24 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B78721F87FE for ; Wed, 25 Apr 2012 15:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MiDiMSZiULT for ; Wed, 25 Apr 2012 15:40:23 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9B621F8534 for ; Wed, 25 Apr 2012 15:40:23 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3PMeMa6011996; Thu, 26 Apr 2012 00:40:22 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3PMeIAR011445; Thu, 26 Apr 2012 00:40:18 +0200 (CEST) Message-ID: <4F987D52.2030208@cisco.com> Date: Thu, 26 Apr 2012 00:40:18 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020001010306030705070605" Cc: Thomas Dietz , "MIB Doctors \(E-mail\)" , Adrian Farrel Subject: [MIB-DOCTORS] Help with a compliance clause (draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 22:40:24 -0000 This is a multi-part message in MIME format. --------------020001010306030705070605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear MIB-doctors, Part of the IESG review, Adrian provided the following feedback on the draft-ietf-ipfix-psamp-mib-04 draft: I would have expected to see some discussion of psampSampUniProbProbability and the non-support of NaN and Infinity in the compliance clauses. Compliance statements often also show the set (minimum? maximum?) of values for objects that need to be supported. Here is the object in question psampSampUniProbProbability OBJECT-TYPE SYNTAX Float64TC MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the probability that a packet is sampled, expressed as a value between 0 and 1. The probability is equal for every packet. A value of 0 means no packet is sampled since the probability is 0. A value of 1 means all packets are sampled since the probability is 1. NaN (not a number) and infinity MUST NOT be used." REFERENCE "RFC5475, Section 5.2.2.1 andRFC5477, Section 8.2 " ::= { psampSampUniProbParamSetEntry 2 } ... psampGroupSampUniProb OBJECT-GROUP OBJECTS { psampSampUniProbAvail, psampSampUniProbProbability } STATUS current DESCRIPTION "These objects are needed if uniform probabilistic sampling is implemented." ::= { psampGroups 4 } I browsed through RFC2580, and I'm not sure how to address this point. Any help is appreciated. For example, an example in a MIB module. Regards, Benoit. --------------020001010306030705070605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear MIB-doctors,

Part of the IESG review, Adrian provided the following feedback on the draft-ietf-ipfix-psamp-mib-04 draft:
I would have expected to see some discussion of 
psampSampUniProbProbability and the non-support of NaN and Infinity
in the compliance clauses. 
Compliance statements often also show the set (minimum? maximum?) of values for objects that need to be supported.
Here is the object in question
   psampSampUniProbProbability OBJECT-TYPE
       SYNTAX      Float64TC
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object specifies the probability that a packet is
           sampled, expressed as a value between 0 and 1.  The
           probability is equal for every packet.  A value of 0 means
           no packet is sampled since the probability is 0. A value
           of 1 means all packets are sampled since the
           probability is 1. NaN (not a number) and infinity MUST NOT
           be used."
       REFERENCE
           "RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2"
       ::= { psampSampUniProbParamSetEntry 2 }

...

   psampGroupSampUniProb OBJECT-GROUP
       OBJECTS {
                 psampSampUniProbAvail,
                 psampSampUniProbProbability
               }
       STATUS  current
       DESCRIPTION
           "These objects are needed if uniform probabilistic sampling
           is implemented."
       ::= { psampGroups 4 }
I browsed through RFC2580, and I'm not sure how to address this point.
Any help is appreciated. For example, an example in a MIB module.

Regards, Benoit.


--------------020001010306030705070605-- From randy_presuhn@mindspring.com Wed Apr 25 19:11:52 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BF121F8848 for ; Wed, 25 Apr 2012 19:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff7FkQGVOyQh for ; Wed, 25 Apr 2012 19:11:51 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 514BF21F8875 for ; Wed, 25 Apr 2012 19:11:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SBqvK4pjO6DSB6wyVCzAhcBgCyQMGGEqh5ltHhrLIslMMuSrZB1Y+Bp+VVdv+4CT; 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 [76.254.52.175] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SNEBS-0007r3-Q1 for mib-doctors@ietf.org; Wed, 25 Apr 2012 22:11:51 -0400 Message-ID: <004201cd2352$251a8d80$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "MIB Doctors \(E-mail\)" References: <4F987D52.2030208@cisco.com> Date: Wed, 25 Apr 2012 19:13:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88c2d23c9e885c15c7fbd35f0c0d5f5319350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.52.175 Subject: Re: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 02:11:52 -0000 Hi - > From: "Benoit Claise" > Cc: "Thomas Dietz" ; "MIB Doctors (E-mail)" ; "Adrian Farrel" > Sent: Wednesday, April 25, 2012 3:40 PM > Subject: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix-psamp-mib-04 draft) > > Dear MIB-doctors, > > Part of the IESG review, Adrian provided the following feedback on the > draft-ietf-ipfix-psamp-mib-04 > draft: > > I would have expected to see some discussion of > psampSampUniProbProbability and the non-support of NaN and Infinity > in the compliance clauses. > Compliance statements often also show the set (minimum? maximum?) > of values for objects that need to be supported. To quote RFC 6340: o Since these textual conventions are defined in terms of the OCTET STRING type, the SMI's mechanisms for formally setting range constraints are not available. MIB designers using these textual conventions will need to use DESCRIPTION clauses to spell out any applicable range constraints beyond those implied by the underlying IEEE types. o Whenever these textual conventions are used in a MIB module, the associated DESCRIPTION clause will need to clearly specify whether denormalized numbers, NaNs ("not a number") or infinities are permitted, along with any special semantics associated with these cases. This is especially important for writeable objects. The problem in this particular case is that the SMI notation doesn't provide a reasonable way to represent the 0.0 to 1.0 range in machine-processable form. Prohibing NaN and the Infinities also seems to be the correct thing to do here. If permitted, what would they *mean* here? Or, more directly, under what circumstances could a non-broken implementation reasonably respond with those values for this object? Since it is not writable, I'm less concerned about issues with denormalized numbers. > Here is the object in question > > psampSampUniProbProbability OBJECT-TYPE > SYNTAX Float64TC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the probability that a packet is > sampled, expressed as a value between 0 and 1. The > probability is equal for every packet. A value of 0 means > no packet is sampled since the probability is 0. A value > of 1 means all packets are sampled since the > probability is 1. NaN (not a number) and infinity MUST NOT > be used." > REFERENCE > "RFC5475, Section 5.2.2.1 andRFC5477, Section 8.2 " > ::= { psampSampUniProbParamSetEntry 2 } > > ... > > psampGroupSampUniProb OBJECT-GROUP > OBJECTS { > psampSampUniProbAvail, > psampSampUniProbProbability > } > STATUS current > DESCRIPTION > "These objects are needed if uniform probabilistic sampling > is implemented." > ::= { psampGroups 4 } > > > I browsed through RFC2580, and I'm not sure how to address this point. > Any help is appreciated. For example, an example in a MIB module. The OBJECT-GROUP also seems reasonable to me. What problem do you see there? Randy From j.schoenwaelder@jacobs-university.de Wed Apr 25 22:03:11 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB09321F88F1 for ; Wed, 25 Apr 2012 22:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+e9JVMacXVE for ; Wed, 25 Apr 2012 22:03:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 906ED21F8777 for ; Wed, 25 Apr 2012 22:03:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCE4E20DB7; Thu, 26 Apr 2012 07:03:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YkpC7gFtc4H4; Thu, 26 Apr 2012 07:03:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D0C420D9D; Thu, 26 Apr 2012 07:03:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5924C1EA667C; Thu, 26 Apr 2012 07:03:09 +0200 (CEST) Date: Thu, 26 Apr 2012 07:03:08 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20120426050308.GA89643@elstar.local> Mail-Followup-To: Benoit Claise , Thomas Dietz , "MIB Doctors (E-mail)" , Adrian Farrel References: <4F987D52.2030208@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F987D52.2030208@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Thomas Dietz , Adrian Farrel , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Help with a compliance clause (draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 05:03:11 -0000 On Thu, Apr 26, 2012 at 12:40:18AM +0200, Benoit Claise wrote: > Dear MIB-doctors, > > Part of the IESG review, Adrian provided the following feedback on > the draft-ietf-ipfix-psamp-mib-04 > draft: > > I would have expected to see some discussion of > psampSampUniProbProbability and the non-support of NaN and Infinity > in the compliance clauses. > Compliance statements often also show the set (minimum? maximum?) of values for objects that need to be supported. > > Here is the object in question > > psampSampUniProbProbability OBJECT-TYPE > SYNTAX Float64TC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the probability that a packet is > sampled, expressed as a value between 0 and 1. The > probability is equal for every packet. A value of 0 means > no packet is sampled since the probability is 0. A value > of 1 means all packets are sampled since the > probability is 1. NaN (not a number) and infinity MUST NOT > be used." > REFERENCE > "RFC5475, Section 5.2.2.1 andRFC5477, Section 8.2 " > ::= { psampSampUniProbParamSetEntry 2 } > I think this should have never been a Float64TC. To represent a probability between 0 and 1, pick a scale factor (e.g. 1000000000) and an Unsigned32 number. This is easy to implement, less ambigious for probabilities such as 0 and 1 and I assume the precision is good enough as well, no? If not, use Unsigned64 and an even bigger scaling factor and this is then surely more precise than the Float64TC will ever be. (It seems this is the only usage of a float number in the MIB.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Thu Apr 26 02:26:43 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D0A21F86E1 for ; Thu, 26 Apr 2012 02:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9KP0HbrqWuT for ; Thu, 26 Apr 2012 02:26:42 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8442B21F85C6 for ; Thu, 26 Apr 2012 02:26:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3Q9Qf71018247; Thu, 26 Apr 2012 11:26:41 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3Q9QetV028837; Thu, 26 Apr 2012 11:26:40 +0200 (CEST) Message-ID: <4F9914D0.9010606@cisco.com> Date: Thu, 26 Apr 2012 11:26:40 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Randy Presuhn References: <4F987D52.2030208@cisco.com> <004201cd2352$251a8d80$6b01a8c0@oemcomputer> In-Reply-To: <004201cd2352$251a8d80$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , Thomas Dietz , Adrian Farrel Subject: Re: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:26:43 -0000 Thanks Randy, Let me copy Arian Farrel, who made the comment, so that he can follow up. Regards, Benoit. > Hi - > >> From: "Benoit Claise" >> Cc: "Thomas Dietz"; "MIB Doctors (E-mail)"; "Adrian Farrel" > >> Sent: Wednesday, April 25, 2012 3:40 PM >> Subject: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix-psamp-mib-04 draft) >> >> Dear MIB-doctors, >> >> Part of the IESG review, Adrian provided the following feedback on the >> draft-ietf-ipfix-psamp-mib-04 >> draft: >> >> I would have expected to see some discussion of >> psampSampUniProbProbability and the non-support of NaN and Infinity >> in the compliance clauses. >> Compliance statements often also show the set (minimum? maximum?) >> of values for objects that need to be supported. > To quote RFC 6340: > o Since these textual conventions are defined in terms of the OCTET > STRING type, the SMI's mechanisms for formally setting range > constraints are not available. MIB designers using these textual > conventions will need to use DESCRIPTION clauses to spell out any > applicable range constraints beyond those implied by the > underlying IEEE types. > > o Whenever these textual conventions are used in a MIB module, the > associated DESCRIPTION clause will need to clearly specify whether > denormalized numbers, NaNs ("not a number") or infinities are > permitted, along with any special semantics associated with these > cases. This is especially important for writeable objects. > > The problem in this particular case is that the SMI notation doesn't provide > a reasonable way to represent the 0.0 to 1.0 range in machine-processable > form. > > Prohibing NaN and the Infinities also seems to be the correct thing to do here. > If permitted, what would they *mean* here? Or, more directly, under what > circumstances could a non-broken implementation reasonably respond > with those values for this object? Since it is not writable, I'm less concerned > about issues with denormalized numbers. > >> Here is the object in question >> >> psampSampUniProbProbability OBJECT-TYPE >> SYNTAX Float64TC >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object specifies the probability that a packet is >> sampled, expressed as a value between 0 and 1. The >> probability is equal for every packet. A value of 0 means >> no packet is sampled since the probability is 0. A value >> of 1 means all packets are sampled since the >> probability is 1. NaN (not a number) and infinity MUST NOT >> be used." >> REFERENCE >> "RFC5475, Section 5.2.2.1 andRFC5477, Section 8.2 > " >> ::= { psampSampUniProbParamSetEntry 2 } >> >> ... >> >> psampGroupSampUniProb OBJECT-GROUP >> OBJECTS { >> psampSampUniProbAvail, >> psampSampUniProbProbability >> } >> STATUS current >> DESCRIPTION >> "These objects are needed if uniform probabilistic sampling >> is implemented." >> ::= { psampGroups 4 } >> >> >> I browsed through RFC2580, and I'm not sure how to address this point. >> Any help is appreciated. For example, an example in a MIB module. > The OBJECT-GROUP also seems reasonable to me. What problem do you > see there? > > Randy > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > From adrian@olddog.co.uk Thu Apr 26 03:03:31 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66C121F86FD for ; Thu, 26 Apr 2012 03:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCkTc0YFwhRp for ; Thu, 26 Apr 2012 03:03:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id C0C2121F863C for ; Thu, 26 Apr 2012 03:03:30 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3QA3Q16020370; Thu, 26 Apr 2012 11:03:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3QA3OYi020342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Apr 2012 11:03:25 +0100 From: "Adrian Farrel" To: "'Benoit Claise'" , "'Randy Presuhn'" References: <4F987D52.2030208@cisco.com> <004201cd2352$251a8d80$6b01a8c0@oemcomputer> <4F9914D0.9010606@cisco.com> In-Reply-To: <4F9914D0.9010606@cisco.com> Date: Thu, 26 Apr 2012 11:03:23 +0100 Message-ID: <09c101cd2393$d15efb80$741cf280$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJyn/gk9tY7aZUVCEnqToCxvNj/wQI8tcqqAaDpSrGVQvOVgA== Content-Language: en-gb Cc: "'MIB Doctors \(E-mail\)'" , 'Thomas Dietz' Subject: Re: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:03:31 -0000 Hi, Note first that this was a Comment not a Discuss. Note also that I am not an expert on Compliance Statements, hence the slight vagueness in my Comment. Looking at Compliance Statements I have known, it would appear that an OBJECT clause under Compliances has a DESCRIPTION that often limits the scope of the object. Adrian > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: 26 April 2012 10:27 > To: Randy Presuhn > Cc: MIB Doctors (E-mail); Adrian Farrel; Thomas Dietz > Subject: Re: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix- > psamp-mib-04 draft) > > Thanks Randy, > > Let me copy Arian Farrel, who made the comment, so that he can follow up. > > Regards, Benoit. > > Hi - > > > >> From: "Benoit Claise" > >> Cc: "Thomas Dietz"; "MIB Doctors (E- > mail)"; "Adrian Farrel" > > > >> Sent: Wednesday, April 25, 2012 3:40 PM > >> Subject: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix- > psamp-mib-04 draft) > >> > >> Dear MIB-doctors, > >> > >> Part of the IESG review, Adrian provided the following feedback on the > >> draft-ietf-ipfix-psamp-mib-04 > >> draft: > >> > >> I would have expected to see some discussion of > >> psampSampUniProbProbability and the non-support of NaN and Infinity > >> in the compliance clauses. > >> Compliance statements often also show the set (minimum? maximum?) > >> of values for objects that need to be supported. > > To quote RFC 6340: > > o Since these textual conventions are defined in terms of the OCTET > > STRING type, the SMI's mechanisms for formally setting range > > constraints are not available. MIB designers using these textual > > conventions will need to use DESCRIPTION clauses to spell out any > > applicable range constraints beyond those implied by the > > underlying IEEE types. > > > > o Whenever these textual conventions are used in a MIB module, the > > associated DESCRIPTION clause will need to clearly specify whether > > denormalized numbers, NaNs ("not a number") or infinities are > > permitted, along with any special semantics associated with these > > cases. This is especially important for writeable objects. > > > > The problem in this particular case is that the SMI notation doesn't provide > > a reasonable way to represent the 0.0 to 1.0 range in machine-processable > > form. > > > > Prohibing NaN and the Infinities also seems to be the correct thing to do here. > > If permitted, what would they *mean* here? Or, more directly, under what > > circumstances could a non-broken implementation reasonably respond > > with those values for this object? Since it is not writable, I'm less concerned > > about issues with denormalized numbers. > > > >> Here is the object in question > >> > >> psampSampUniProbProbability OBJECT-TYPE > >> SYNTAX Float64TC > >> MAX-ACCESS read-only > >> STATUS current > >> DESCRIPTION > >> "This object specifies the probability that a packet is > >> sampled, expressed as a value between 0 and 1. The > >> probability is equal for every packet. A value of 0 means > >> no packet is sampled since the probability is 0. A value > >> of 1 means all packets are sampled since the > >> probability is 1. NaN (not a number) and infinity MUST NOT > >> be used." > >> REFERENCE > >> "RFC5475, Section 5.2.2.1 5.2.2.1> andRFC5477, Section 8.2 > > " > >> ::= { psampSampUniProbParamSetEntry 2 } > >> > >> ... > >> > >> psampGroupSampUniProb OBJECT-GROUP > >> OBJECTS { > >> psampSampUniProbAvail, > >> psampSampUniProbProbability > >> } > >> STATUS current > >> DESCRIPTION > >> "These objects are needed if uniform probabilistic sampling > >> is implemented." > >> ::= { psampGroups 4 } > >> > >> > >> I browsed through RFC2580, and I'm not sure how to address this point. > >> Any help is appreciated. For example, an example in a MIB module. > > The OBJECT-GROUP also seems reasonable to me. What problem do you > > see there? > > > > Randy > > > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > > > From Thomas.Dietz@neclab.eu Thu Apr 26 03:36:40 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5A121F87A3 for ; Thu, 26 Apr 2012 03:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axw7833x+06Z for ; Thu, 26 Apr 2012 03:36:39 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C57F121F87A2 for ; Thu, 26 Apr 2012 03:36:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C271E100DA6; Thu, 26 Apr 2012 12:33:55 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOJNIZxk+jl4; Thu, 26 Apr 2012 12:33:55 +0200 (CEST) Received: by mailer1.neclab.eu (Postfix, from userid 1001) id A218C100E36; Thu, 26 Apr 2012 12:33:55 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E4061100DA6; Thu, 26 Apr 2012 12:33:29 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 12:35:51 +0200 From: Thomas Dietz To: Juergen Schoenwaelder , Benoit Claise Thread-Topic: [MIB-DOCTORS] Help with a compliance clause (draft-ietf-ipfix-psamp-mib-04 draft) Thread-Index: AQHNIzRrcWh1/4PX3kSoDGPYvhQ/xZasa80AgAB8uXA= Date: Thu, 26 Apr 2012 10:35:51 +0000 Message-ID: <75581E268A48F849916117B977D76D3734D8695F@Polydeuces.office.hd> References: <4F987D52.2030208@cisco.com> <20120426050308.GA89643@elstar.local> In-Reply-To: <20120426050308.GA89643@elstar.local> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01CD23A9.1AC389C0" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 26 Apr 2012 03:47:33 -0700 Cc: Thomas Dietz , Adrian Farrel , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Help with a compliance clause (draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:36:40 -0000 ------=_NextPart_000_0019_01CD23A9.1AC389C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear J=FCrgen, all, we had exactly that in some early versions of the draft. Then we had = some lengthy discussions what is the best way to encode the float64 value = from the info model (there it IS float64). If I remember correctly we voted = for some kind of float because we wanted to avoid conversion from the info = model to the MIB and vice versa. Finally, we found the Float64TC and re-used = that one. As conclusion, if we accept the info model as primary source of = information (because this is what is transmitted on the wire by the IPFIX protocol) = then we keep precision and avoid conversion between formats when using = Float64TC. Best Regards, Thomas --=20 Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, April 26, 2012 7:03 AM > To: Benoit Claise > Cc: Thomas Dietz; MIB Doctors (E-mail); Adrian Farrel > Subject: Re: [MIB-DOCTORS] Help with a compliance clause (draft-ietf- > ipfix-psamp-mib-04 draft) >=20 > On Thu, Apr 26, 2012 at 12:40:18AM +0200, Benoit Claise wrote: > > Dear MIB-doctors, > > > > Part of the IESG review, Adrian provided the following feedback on > > the draft-ietf-ipfix-psamp-mib-04 > > draft: > > > > I would have expected to see some discussion of > > psampSampUniProbProbability and the non-support of NaN and = Infinity > > in the compliance clauses. > > Compliance statements often also show the set (minimum? maximum?) = of > values for objects that need to be supported. > > > > Here is the object in question > > > > psampSampUniProbProbability OBJECT-TYPE > > SYNTAX Float64TC > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the probability that a packet is > > sampled, expressed as a value between 0 and 1. The > > probability is equal for every packet. A value of 0 = means > > no packet is sampled since the probability is 0. A value > > of 1 means all packets are sampled since the > > probability is 1. NaN (not a number) and infinity MUST = NOT > > be used." > > REFERENCE > > "RFC5475, Section 5.2.2.1 > andRFC5477, = Section > 8.2 " > > ::=3D { psampSampUniProbParamSetEntry 2 } > > >=20 > I think this should have never been a Float64TC. To represent a > probability between 0 and 1, pick a scale factor (e.g. 1000000000) and > an Unsigned32 number. This is easy to implement, less ambigious for > probabilities such as 0 and 1 and I assume the precision is good > enough as well, no? If not, use Unsigned64 and an even bigger scaling > factor and this is then surely more precise than the Float64TC will > ever be. (It seems this is the only usage of a float number in the > MIB.) >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 ------=_NextPart_000_0019_01CD23A9.1AC389C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQsMIIEKAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICZzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MjYxMDM1NDZaMCMGCSqGSIb3 DQEJBDEWBBTE471KpT/OmFbD7+Dcf5eYFu1h8DCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCG SAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzANBgkqhkiG9w0BAQEFAASCAQB6 M2zJ3o3bOOPgXVSrDm52BlboVUqLqW3FN5QUWemcL9xoaF6/WeNul278KAlyv09TLeelRXydPgdE +mAPcIKNeM09RwYupdf5sGJ0WsDmLmHWENtGqtFP/7KD4b70Leo9dkyRRMvnvQRvS70QN/eAfbRI 8nFl9vtuyhe8YB19LUX3xgLLzRirqmbHO7WcO+nY9uzHOKkVr8AAf1da1iIGiFjn7DqmXlwPMo/V tG/0XobHfDxGGRxPobQ6CxK6yobH3It0lrOEXJHsEaqLLAbG2Eg/tYlj9bP33JUTj+0mg8OgHhs+ RtRH/4o6EfSKlko/oOpz1HbRnrbs7mxZJychAAAAAAAA ------=_NextPart_000_0019_01CD23A9.1AC389C0-- From j.schoenwaelder@jacobs-university.de Thu Apr 26 03:55:45 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A531321F882C for ; Thu, 26 Apr 2012 03:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.094 X-Spam-Level: X-Spam-Status: No, score=-102.094 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J3wwGOaJqGg for ; Thu, 26 Apr 2012 03:55:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2BB21F881C for ; Thu, 26 Apr 2012 03:55:45 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 638B220E1F; Thu, 26 Apr 2012 12:55:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4sWETjMBkBT7; Thu, 26 Apr 2012 12:55:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E11CF20E16; Thu, 26 Apr 2012 12:55:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AC4291EA7E9A; Thu, 26 Apr 2012 12:55:44 +0200 (CEST) Date: Thu, 26 Apr 2012 12:55:44 +0200 From: Juergen Schoenwaelder To: Thomas Dietz Message-ID: <20120426105542.GA91124@elstar.local> Mail-Followup-To: Thomas Dietz , Benoit Claise , Thomas Dietz , "MIB Doctors (E-mail)" , Adrian Farrel References: <4F987D52.2030208@cisco.com> <20120426050308.GA89643@elstar.local> <75581E268A48F849916117B977D76D3734D8695F@Polydeuces.office.hd> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <75581E268A48F849916117B977D76D3734D8695F@Polydeuces.office.hd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Thomas Dietz , Adrian Farrel , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Help with a compliance clause (draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:55:45 -0000 On Thu, Apr 26, 2012 at 10:35:51AM +0000, Thomas Dietz wrote: > Dear Jürgen, all, > > we had exactly that in some early versions of the draft. Then we had some > lengthy discussions what is the best way to encode the float64 value from > the info model (there it IS float64). If I remember correctly we voted for > some kind of float because we wanted to avoid conversion from the info model > to the MIB and vice versa. Finally, we found the Float64TC and re-used that > one. > > As conclusion, if we accept the info model as primary source of information > (because this is what is transmitted on the wire by the IPFIX protocol) then > we keep precision and avoid conversion between formats when using Float64TC. Dear Thomas, thanks for the explanation. Perhaps the info model should not have used floats... but luckily I do not have to implement 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 randy_presuhn@mindspring.com Thu Apr 26 09:36:33 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF221E8137 for ; Thu, 26 Apr 2012 09:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.516 X-Spam-Level: X-Spam-Status: No, score=-101.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxpsG8iT8mIe for ; Thu, 26 Apr 2012 09:36:32 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id A387121E80B4 for ; Thu, 26 Apr 2012 09:36:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=S0FZcBMhdqtjSyeVDv2zguHLbtTuZgGA0cg/f6Bow9pdU8ObFtCfQlymj7bB/dkK; h=Received:Message-ID:From:To:Cc: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 [76.254.52.175] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SNRfG-0004RS-Gf; Thu, 26 Apr 2012 12:35:30 -0400 Message-ID: <002001cd23ca$cd492020$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Juergen Schoenwaelder" , "Thomas Dietz" References: <4F987D52.2030208@cisco.com> <20120426050308.GA89643@elstar.local><75581E268A48F849916117B977D76D3734D8695F@Polydeuces.office.hd> <20120426105542.GA91124@elstar.local> Date: Thu, 26 Apr 2012 09:36:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f883fbc103da2164d79480954abe11963fb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.52.175 Cc: Thomas Dietz , "MIB Doctors \(E-mail\)" , Adrian Farrel Subject: Re: [MIB-DOCTORS] Help with a compliance clause (draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:36:33 -0000 Hi - I'm with Juergen on this one. Quoting that RFC again: o Floating-point numbers are useful if the number space needs to cover a large dynamic range. For number spaces with a limited range, fixed-point numbers can be more efficient and more precise. o Floating-point numbers are typically the wrong answer for data that is truly decimal or can be handled adequately by re-thinking the units and representing the scaled numbers as integers. But I do understand the desire to avoid conversions, and if the WG has discussed the tradeoffs, I have no objections. Randy ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Thomas Dietz" > Cc: "Thomas Dietz" ; "Adrian Farrel" ; "MIB Doctors (E-mail)" > Sent: Thursday, April 26, 2012 3:55 AM > Subject: Re: [MIB-DOCTORS] Help with a compliance clause (draft-ietf-ipfix-psamp-mib-04 draft) > > On Thu, Apr 26, 2012 at 10:35:51AM +0000, Thomas Dietz wrote: > Dear Jürgen, all, > > we had exactly that in some early versions of the draft. Then we had some > lengthy discussions what is the best way to encode the float64 value from > the info model (there it IS float64). If I remember correctly we voted for > some kind of float because we wanted to avoid conversion from the info model > to the MIB and vice versa. Finally, we found the Float64TC and re-used that > one. > > As conclusion, if we accept the info model as primary source of information > (because this is what is transmitted on the wire by the IPFIX protocol) then > we keep precision and avoid conversion between formats when using Float64TC. Dear Thomas, thanks for the explanation. Perhaps the info model should not have used floats... but luckily I do not have to implement this. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors From randy_presuhn@mindspring.com Thu Apr 26 09:46:45 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F7811E80A0 for ; Thu, 26 Apr 2012 09:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+icVDstDkQO for ; Thu, 26 Apr 2012 09:46:45 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD7711E809D for ; Thu, 26 Apr 2012 09:46:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=k8lV3ka486ShUsWEgjSp/7KhzNKo6n9ZFReLwFZAVViv6bj2g4u0tVjddT8HwRth; h=Received:Message-ID:From:To:Cc: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 [76.254.52.175] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SNRq7-0008V6-4f; Thu, 26 Apr 2012 12:46:43 -0400 Message-ID: <002f01cd23cc$5ec0b300$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: , "'Benoit Claise'" References: <4F987D52.2030208@cisco.com> <004201cd2352$251a8d80$6b01a8c0@oemcomputer> <4F9914D0.9010606@cisco.com> <09c101cd2393$d15efb80$741cf280$@olddog.co.uk> Date: Thu, 26 Apr 2012 09:48:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f8877958e0deda3fb43c1200f628b33ea77350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.52.175 Cc: "'MIB Doctors \(E-mail\)'" , 'Thomas Dietz' Subject: Re: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix-psamp-mib-04 draft) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:46:45 -0000 Hi - > From: "Adrian Farrel" > To: "'Benoit Claise'" ; "'Randy Presuhn'" > Cc: "'MIB Doctors (E-mail)'" ; "'Thomas Dietz'" > Sent: Thursday, April 26, 2012 3:03 AM > Subject: RE: [MIB-DOCTORS] Help with a compliance clause(draft-ietf-ipfix-psamp-mib-04 draft) ... > Looking at Compliance Statements I have known, it would appear that an OBJECT > clause under Compliances has a DESCRIPTION that often limits the scope of the > object. The normal case when this would be done is when an implementation conforming to a particular MODULE-COMPLIANCE statement only needs to support a subset of the values permitted by the OBJECT-TYPE. One would include the SYNTAX or WRITE-SYNTAX components in the OBJECT clause only when the set of values that a conformant implementation must support is more limited than what the OBJECT-TYPE specifies. Randy