From dromasca@avaya.com Wed Apr 4 07:50:56 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@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: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group 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: eman@ietfa.amsl.com Delivered-To: eman@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: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group 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: eman@ietfa.amsl.com Delivered-To: eman@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: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group 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: eman@ietfa.amsl.com Delivered-To: eman@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 X-Mailman-Approved-At: Wed, 04 Apr 2012 22:13:09 -0700 Cc: MIB Doctors , eman@ietf.org Subject: Re: [eman] [MIB-DOCTORS] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group 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 brads@coraid.com Wed Apr 11 22:13:30 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B9221F857D for ; Wed, 11 Apr 2012 22:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 csoSuXII9-gx for ; Wed, 11 Apr 2012 22:13:28 -0700 (PDT) Received: from server505.appriver.com (server505h.appriver.com [98.129.35.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6721F857A for ; Wed, 11 Apr 2012 22:13:24 -0700 (PDT) X-Note-AR-ScanTimeLocal: 4/12/2012 12:13:24 AM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G259 G260 G261 G262 G266 G267 G278 G369 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 210496480; Thu, 12 Apr 2012 00:13:24 -0500 Received: from MBX22.exg5.exghost.com ([169.254.1.210]) by HT05.exg5.exghost.com ([98.129.23.150]) with mapi; Thu, 12 Apr 2012 00:13:23 -0500 From: Brad Schoening To: Juergen Quittek Date: Thu, 12 Apr 2012 00:13:20 -0500 Thread-Topic: [eman] I-D Action: draft-ietf-eman-battery-mib-05.txt Thread-Index: Ac0YavsxPNHzNktySVC3mLUGYCHSEA== Message-ID: In-Reply-To: <20120307134851.24625.52709.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-battery-mib-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 05:13:30 -0000 Juergen, Rolf, & Thomas, I have reviewed the recently update to the draft Battery MIB and have the below comments. Most are simple syntax issues with a few issues of substance around entPhysicalClass and unit declarations. ------------------ Sec 1 - Introduction "that provides means for" -> suggest "that provides a means for" "Battery MIB module serves for" -> suggest "Battery MIB module provides for" instead "the Battery MIB allows to monitor" -> suggest "allows us to monitor" "There is already instrumentation for monitoring battery status on many battery-driven devices=8A" =09 This is a little hard to follow because you say 'already' and then qualify it with 'many'. Perhaps re- arrange this to=20 -->"Many battery-driven devices have existing instrumentation for monitoring battery status=8A" "Not explicitly in scope of definitions in this document are very small backup batteries'"=09 Sec 3.1 MIB Module Structure -->What "definition" is being referred to here? The EMAN requirements? You state "The kind of entity in the entPhysicalTable of the Entity MIB module is indicated by the value of the enumeration object entPhysicalClass. Since there is no value called 'battery' defined for this object, it is RECOMMENDED that for batteries the value of this object is chosen to be powerSupply(6)." -> Why not "other(1)"? It seems misleading to call a battery a power supply as traditionally a power supply is also a transformer that performs AC/DC conversion. If a managed entity for powerSupply(6) already exists on a device, then this might negatively affect management tools that look for and manage power supplies. batteryLowAlarmCharge batteryLowAlarmVoltage -> Is there a reason 'Alarm' is inserted in the middle between "low" and "charge" and not at the beginning or end? I think it would be more readable if it was batteryLowChargeAlarm. Same for High/LowAlarmTemperature. Sec 3.2 Battery Technologies "Battery type distinguished primary (not-rechargeable) batteries from secondary (rechargeable) batteries." -> this statement is correct, but it had worried me at first because the terms primary/secondary are not that commonly used. I think a sentence or two to explain primary cells and secondary cells might be helpful here. "massively used technologies are often replaced by successor technologies" -> massively is a bold word. You could soften this by stating "widely used technologies=8A" "can be added to the IANA registry if new technologies get developed=8A" -> suggest "if new technologies are developed" -> The table with battery technology needs to be edited for case consistency. You have "Zinc-carbon" and "lithium-iron", and "Lithium ion". Sec 4 Definitions batteryDesignVoltage OBJECT-TYPE SYNTAX Unsigned32 UNITS "milllivolt" batteryDesignCapacity OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliampere hours" batteryMaxChargingCurrent SYNTAX Unsigned32 UNITS "milliampere" -> For unit scale, the UPS-MIB uses 0.1 Amp DC. I'm not sure which form is preferred, milliamp or 0.01 Amp, so long as we are using the most common syntax to represent scale. Below are attributes from the UPS MIB upsBatteryVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Volt DC" upsBatteryCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 Amp DC" -> Also, should you clarify that the measured values are in DC? batteryActualCharge OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliamphere hours" -> This would max-out at 4294 k-amp hours and might be best if it was an Unsigned64 to provide greater headroom. =09 "This notification can be generated when the actual temperature=8A" -> Why 'actual'? If its a measured temperature, it would be subject to drift from actual. Section 5 =AD Security Considerations "older and less performant as required for stable operation" -> suggest "then required for" "this may on one side lead to a costly too early replacement of a battery. But it may also cause That too old or too weak batteries are used. This may have the consequence that a battery cannot long enough provide power." -> needs to be re-phrased "that have legitimate rights to indeed GET or SET" -> the 'indeed' needs to be re-phrased or just removed Section 6.2 =AD Battery Technology Registration "18 values for =8A" -> Generally, you should not start a sentence with a number, use "Eighteen values for=8A" Section 9.2 =AD Informative References [I-D.ietf-eman-framework]=8A Silver, L. [I-D.ietf-eman-energy-monitoring-mib] .. Silver, L. -> You've swapped the town I reside in for my name. It should be "Schoening, B." Regards, Brad Schoening Little Silver, New Jersey On 3/7/12 8:48 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Energy Management Working >Group of the IETF. > > Title : Definition of Managed Objects for Battery Monitoring > Author(s) : Juergen Quittek > Rolf Winter > Thomas Dietz > Filename : draft-ietf-eman-battery-mib-05.txt > Pages : 30 > Date : 2012-03-07 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it defines managed objects that provide information on > the status of batteries in managed devices. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-05.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-05.txt > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Mon Apr 16 02:01:01 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@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: [eman] [MIB-DOCTORS] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group 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: eman@ietfa.amsl.com Delivered-To: eman@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] Cc: eman@ietf.org Subject: Re: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group 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: eman@ietfa.amsl.com Delivered-To: eman@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: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 08:54:14 -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: eman@ietfa.amsl.com Delivered-To: eman@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: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group 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 moulchan@cisco.com Thu Apr 19 02:42:20 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@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] Cc: MIB Doctors , eman@ietf.org Subject: Re: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group 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 dromasca@avaya.com Thu Apr 19 02:51:54 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@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: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group 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 j.schoenwaelder@jacobs-university.de Thu Apr 19 03:26:42 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@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: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group 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