From nobody Wed Nov 5 02:18:34 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5594A1A7002 for ; Wed, 5 Nov 2014 02:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l1BLVBtJJUn for ; Wed, 5 Nov 2014 02:18:29 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEAB1A002F for ; Wed, 5 Nov 2014 02:18:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 47944108849; Wed, 5 Nov 2014 11:18:27 +0100 (CET) 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 7tc1CR54il9a; Wed, 5 Nov 2014 11:18:27 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 23DBE108845; Wed, 5 Nov 2014 11:18:23 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.63]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Wed, 5 Nov 2014 11:18:22 +0100 From: Juergen Quittek To: "eman@ietf.org" Thread-Topic: [eman] Comments on draft-ietf-eman-battery-mib-12 Thread-Index: AQHPPhybEdWlCCzcRUOaKUrpt9HQRpv59myggFlJJ5A= Date: Wed, 5 Nov 2014 10:18:22 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd> References: <201403121757.NAA24671@adminfs.snmp.com> <9AB93E4127C26F4BA7829DEFDCE5A6E894C4AADA@PALLENE.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E894C4AADA@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.165] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/pSFHcxXSdfTHcpPDVirmiRRZqls Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-12 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2014 10:18:33 -0000 Dear all, Here is a proposal on the one open issues resulting from Alan's very helpfu= l comments. The issues concerns the battery capacity for which we use an Unsigned64TC i= n order to be able to support batteries with more than 4MAh. The correct co= mment from Alan was that if we do so, we should for consistency also suppor= t corresponding 64-bit values for the objects we have concerning the electr= ic current. For this we would need to introduce a new Signed64TC. This is a= ll possible and no technical problem. However, I checked for existing battery sizes. It shows that all kinds of b= atteries that are used in electric vehicles or that you can by as energy st= orage for private households are well covered if we just use Unsigned32 for= capacity values. If you go for industrial use, very large batteries are de= livered in units of in 40-foot intermodal freight shipping containers. Even= for the total capacity of such container, the Unsigned32 value would fit, = although there would be not much headroom for further increases of battery = capacity per container. However, these containers are not organized as a "s= ingle" battery, but as an array of multiple batteries. And each individual = one would be modeled as a separate row in the batteryTable of our MIB modul= e. For the individual tables, I do not see a problem, with modeling them by= Unsigned32 values. So, my proposal is removing the inconsistency addressed by Alan by revertin= g to Unsigned32 bit values for all objects related to battery capacity. Cheers, Juergen > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek > Sent: Dienstag, 9. September 2014 16:39 > To: Alan Luchuk; eman@ietf.org > Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-12 >=20 > Dear Alan, > Here comes a very late reply on your message. It got lost in our records, > because at that time you had two sets of comments and I found a message > from you at that time stating "thank you for considering my comments". Bu= t > you message was referring to another set. Fortunately, Benoit discovered > that your comments have not been included and I come back to them right > now. >=20 > Your comments are highly appreciated and I agree on most of them. The > next version -14 will include according changes. >=20 > There is only a comment that I am not sure how to deal with it. It concer= ns > the Unsigned64TC for capacity. Please find a reply inline below. >=20 > Best regards, > Juergen >=20 >=20 > > -----Original Message----- > > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Alan Luchuk > > Sent: Mittwoch, 12. M=E4rz 2014 18:57 > > To: eman@ietf.org > > Subject: [eman] Comments on draft-ietf-eman-battery-mib-12 > > > > Hello, > > > > Here are comments on draft-ietf-eman-battery-mib-12.txt. I think > > only the last issue in the list may be a true problem; it is easily > > fixed. There is one technical issue that might be worthy of further > > consideration. The rest are these are typos or grammatical nits. > > > > I hope these are helpful to the EMAN WG. > > > > Regards, > > --Alan > > > > > > > > Page 3, Introduction (typo) > > ---------------------------- > > > > The second paragraph from the bottom contains the sentence: > > > > Many battery-driven devices have existing instrumentation for > > monitoring the battery status, because this is already needed for > > local control of the battery by the device. > > > > I think the comma is not needed; perhaps the sentence should read: > > > > Many battery-driven devices have existing instrumentation for > > monitoring the battery status because this is already needed for > > local control of the battery by the device. > > > > > > > > Page 4, Introduction (typo) > > --------------------------- > > > > The first paragraph from the top contains the sentence: > > > > The former allows tracing a battery and allows continuous monitoring > > even if the battery is e.g. installed in another device." > > > > I think the "e.g." is not needed; perhaps the sentence should read: > > > > The former allows tracing a battery and allows continuous monitoring > > even if the battery is installed in another device." > > > > > > > > Page 5, MIB Module Structure (grammer) > > -------------------------------------- > > > > The third paragraph from the top reads: > > > > If batteries are replaced, and the replacing battery uses the same > > ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ > > physical connector as the replaced battery, then the replacing > > battery SHOULD be indexed with the same value of object > > entPhysicalIndex as the replaced battery. > > > > In the first clause the subject is plural, in the second clause, the > > subject is singular. Perhaps the sentence should read: > > > > If a battery is replaced, and the replacing battery uses the same > > ^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ > > physical connector as the replaced battery, then the replacing > > battery SHOULD be indexed with the same value of object > > entPhysicalIndex as the replaced battery. > > > > The same text appears in the description clause for the batteryTable > > on page 10. > > > > > > > > Page 5, MIB Module Structure (nit) > > ---------------------------------- > > > > The last paragraph on page 5 and the first paragraph on page 6 mention > > three groups of objects: objects with OIDs ending with 1-10, objects > > with OIDs ending with 11-18, and objects with OIDs ending with 20-25. > > > > The batteryCellIdentifier object ends with SID 19 and is not included > > in any of the three groups. > > > > > > > > Page 13, DESCRIPTION for batteryTechnology > > ------------------------------------------ > > > > The DESCRIPTION for batteryTechnology reads: > > > > "This object indicates the technology used by the battery. > > Numbers identifying battery types are registered at IANA. > > A current list of assignments can be found at > > . > > > > Value 0 (unknown) MUST be used if the type of battery > > cannot be determined. > > > > Value 1 (other) can be used if the battery type is known > > but not one of the types already registered at IANA." > > > > I tried to access the URL shown above, and could not. I assume it has > > not yet been created by IANA. > > > > Also, the values and enumeration names do not match the table shown in > > section 3.2 on page 7. I think this part of the DESCRIPTION should rea= d: > > > > "Value 1 (unknown) MUST be used if the type of battery > > cannot be determined. > > > > Value 2 (other) can be used if the battery type is known > > but not one of the types already registered at IANA." > > > > > > > > Page 14, batteryMaxChargingCurrent (possible technical issue) > > ------------------------------------------------------------- > > > > Between drafts -11 and -12, the battery capacity values were increased > > in size from an Unsigned32 to an Unsigned64TC to accomodate very high > > capacity batteries. > > > > For batteries with a capacity large enough to require an Unsigned64TC > > is it sufficient to have a batteryMaxChargingCurrent limited to an > > Unsigned32? > > > > For example, if a battery is ever built that has a capacity that must > > be reported with the maximum value of the Unsigned64TC > > batteryDesignCapacity, the maximum allowed charging current for that > > battery might be too large to report with the Unsigned32 > > batteryMaxChargingCurrent. > > > > > > This same issue might apply to the batteryTrickleChargingCurrent MIB > > object on Page 14, as well as the batteryActualCurrent MIB object on > > Page 19. > > > > > > Not sure what the best course of action is here. >=20 > We could do so, but then we have to change further objects related to The > current including batteryActualCurrent which is a signed integer. > We do not yet have a TC for Integer64. >=20 > > > > Page 16, DESCRIPTION for batteryChargingCycleCount > > -------------------------------------------------- > > > > The second paragraph of the DESCRIPTION for batteryChargingCycleCount > > reads: > > > > "For batteries of type primary(1) the value of this object is > > always 0." > > > > This enumeration name/number does not match the enumerated values > > listed for the batteryType MIB object on page 12/13: > > > > batteryType OBJECT-TYPE > > SYNTAX INTEGER { > > unknown(1), > > other(2), > > primary(3), > > rechargeable(4), > > capacitor(5) > > } > > > > Also, I think the charging cycle count only applies to a batteryType > > of rechargeable(4), so would rewording this second paragraph make > sense? > > > > "For batteries of any type other than rechargeable(4), the value of > > this object is always 0." > > > > > > > > Page 17, DESCRIPTION for batteryChargingAdminState (nit) > > -------------------------------------------------------- > > > > The first sentence of the first paragraph of the DESCRIPTION for > > batteryChargingAdminState reads: > > > > "The value of this object indicates the desired status of > > the charging state of the battery. > > > > Perhaps the following text is a little more concise: > > > > "The value of this object indicates the desired charging > > state of the battery. > > > > > > > > Page 28, batteryTemperatureNotification (problem) > > ------------------------------------------------- > > > > OBJECT batteryTemperatureNotification > > MIN-ACCESS read-only > > DESCRIPTION > > "A compliant implementation is not required > > to support set operations to this object." > > > > A MIB checker squawked about batteryTemperatureNotification is not > > defined as an OBJECT-TYPE. > > > > > > Should this be removed from the BATTERY-MIB? >=20 > Good catch: This should have been an object. > I will replace batteryTemperatureNotification with > batteryAlarmHighTemperature. >=20 > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From nobody Wed Nov 5 08:00:02 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B344A1A89AC for ; Wed, 5 Nov 2014 08:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eepKl_ybyb9 for ; Wed, 5 Nov 2014 07:59:57 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8B11A8978 for ; Wed, 5 Nov 2014 07:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11218; q=dns/txt; s=iport; t=1415203184; x=1416412784; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TgLMyBZs0rRKdW46tZueTbSaLIBUWEEzoPAQ0pkLtK0=; b=Hg35UPa6xE5b5JlSGGAZohtXygfwfrRc0aLPD5tWL50SSwf8Py2v6eab 40Vl4vacMbtEE6iWjt66fZEj44UeDsJY1yikVHfZhurugfZsSzygpEp6b rk1uxGe7fupPCjU/gws5OgbXyPStNzscpR4xzpJpND4ISA2s/6RWdw3I/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFACNIWlStJA2F/2dsb2JhbABcgw5UWQTNEAqHTQKBGBYBAQEBAX2EAgEBAQMBAQEBaxcEAgEIEQQBASgHJwsUCQgCBAESCYgvCQ3KWwEBAQEBAQEBAQEBAQEBAQEBAQEBAReORoFjEA8eMgaERQWGN4UGhC6CNocXhFiBMYNMgzJTiUqECYN4bIEGAR8igQMBAQE X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="93624419" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 05 Nov 2014 15:59:43 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sA5Fxh4u011559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Nov 2014 15:59:43 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.81]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 5 Nov 2014 09:59:43 -0600 From: "John Parello (jparello)" To: Juergen Quittek , "eman@ietf.org" Thread-Topic: [eman] Comments on draft-ietf-eman-battery-mib-12 Thread-Index: AQHPPhyR01Pf0T/df0iAad42tJCXWZv6T0sAgFlcuAD//9k+gA== Date: Wed, 5 Nov 2014 15:59:42 +0000 Message-ID: References: <201403121757.NAA24671@adminfs.snmp.com> <9AB93E4127C26F4BA7829DEFDCE5A6E894C4AADA@PALLENE.office.hd> <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.67.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/-EqWuGRCez8SEuTOFlPqCYGfheg Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-12 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2014 16:00:00 -0000 +1 Sounds reasonable Jp On 11/5/14 2:18 AM, "Juergen Quittek" wrote: >Dear all, > >Here is a proposal on the one open issues resulting from Alan's very >helpful comments. > >The issues concerns the battery capacity for which we use an Unsigned64TC >in order to be able to support batteries with more than 4MAh. The correct >comment from Alan was that if we do so, we should for consistency also >support corresponding 64-bit values for the objects we have concerning >the electric current. For this we would need to introduce a new >Signed64TC. This is all possible and no technical problem. > >However, I checked for existing battery sizes. It shows that all kinds of >batteries that are used in electric vehicles or that you can by as energy >storage for private households are well covered if we just use Unsigned32 >for capacity values. If you go for industrial use, very large batteries >are delivered in units of in 40-foot intermodal freight shipping >containers. Even for the total capacity of such container, the Unsigned32 >value would fit, although there would be not much headroom for further >increases of battery capacity per container. However, these containers >are not organized as a "single" battery, but as an array of multiple >batteries. And each individual one would be modeled as a separate row in >the batteryTable of our MIB module. For the individual tables, I do not >see a problem, with modeling them by Unsigned32 values. > >So, my proposal is removing the inconsistency addressed by Alan by >reverting to Unsigned32 bit values for all objects related to battery >capacity. > >Cheers, > Juergen > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek >> Sent: Dienstag, 9. September 2014 16:39 >> To: Alan Luchuk; eman@ietf.org >> Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-12 >>=20 >> Dear Alan, >> Here comes a very late reply on your message. It got lost in our >>records, >> because at that time you had two sets of comments and I found a message >> from you at that time stating "thank you for considering my comments". >>But >> you message was referring to another set. Fortunately, Benoit discovered >> that your comments have not been included and I come back to them right >> now. >>=20 >> Your comments are highly appreciated and I agree on most of them. The >> next version -14 will include according changes. >>=20 >> There is only a comment that I am not sure how to deal with it. It >>concerns >> the Unsigned64TC for capacity. Please find a reply inline below. >>=20 >> Best regards, >> Juergen >>=20 >>=20 >> > -----Original Message----- >> > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Alan Luchuk >> > Sent: Mittwoch, 12. M=E4rz 2014 18:57 >> > To: eman@ietf.org >> > Subject: [eman] Comments on draft-ietf-eman-battery-mib-12 >> > >> > Hello, >> > >> > Here are comments on draft-ietf-eman-battery-mib-12.txt. I think >> > only the last issue in the list may be a true problem; it is easily >> > fixed. There is one technical issue that might be worthy of further >> > consideration. The rest are these are typos or grammatical nits. >> > >> > I hope these are helpful to the EMAN WG. >> > >> > Regards, >> > --Alan >> > >> > >> > >> > Page 3, Introduction (typo) >> > ---------------------------- >> > >> > The second paragraph from the bottom contains the sentence: >> > >> > Many battery-driven devices have existing instrumentation for >> > monitoring the battery status, because this is already needed for >> > local control of the battery by the device. >> > >> > I think the comma is not needed; perhaps the sentence should read: >> > >> > Many battery-driven devices have existing instrumentation for >> > monitoring the battery status because this is already needed for >> > local control of the battery by the device. >> > >> > >> > >> > Page 4, Introduction (typo) >> > --------------------------- >> > >> > The first paragraph from the top contains the sentence: >> > >> > The former allows tracing a battery and allows continuous >>monitoring >> > even if the battery is e.g. installed in another device." >> > >> > I think the "e.g." is not needed; perhaps the sentence should read: >> > >> > The former allows tracing a battery and allows continuous >>monitoring >> > even if the battery is installed in another device." >> > >> > >> > >> > Page 5, MIB Module Structure (grammer) >> > -------------------------------------- >> > >> > The third paragraph from the top reads: >> > >> > If batteries are replaced, and the replacing battery uses the same >> > ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ >> > physical connector as the replaced battery, then the replacing >> > battery SHOULD be indexed with the same value of object >> > entPhysicalIndex as the replaced battery. >> > >> > In the first clause the subject is plural, in the second clause, the >> > subject is singular. Perhaps the sentence should read: >> > >> > If a battery is replaced, and the replacing battery uses the same >> > ^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ >> > physical connector as the replaced battery, then the replacing >> > battery SHOULD be indexed with the same value of object >> > entPhysicalIndex as the replaced battery. >> > >> > The same text appears in the description clause for the batteryTable >> > on page 10. >> > >> > >> > >> > Page 5, MIB Module Structure (nit) >> > ---------------------------------- >> > >> > The last paragraph on page 5 and the first paragraph on page 6 mention >> > three groups of objects: objects with OIDs ending with 1-10, objects >> > with OIDs ending with 11-18, and objects with OIDs ending with 20-25. >> > >> > The batteryCellIdentifier object ends with SID 19 and is not included >> > in any of the three groups. >> > >> > >> > >> > Page 13, DESCRIPTION for batteryTechnology >> > ------------------------------------------ >> > >> > The DESCRIPTION for batteryTechnology reads: >> > >> > "This object indicates the technology used by the battery. >> > Numbers identifying battery types are registered at IANA. >> > A current list of assignments can be found at >> > . >> > >> > Value 0 (unknown) MUST be used if the type of battery >> > cannot be determined. >> > >> > Value 1 (other) can be used if the battery type is known >> > but not one of the types already registered at IANA." >> > >> > I tried to access the URL shown above, and could not. I assume it has >> > not yet been created by IANA. >> > >> > Also, the values and enumeration names do not match the table shown in >> > section 3.2 on page 7. I think this part of the DESCRIPTION should >>read: >> > >> > "Value 1 (unknown) MUST be used if the type of battery >> > cannot be determined. >> > >> > Value 2 (other) can be used if the battery type is known >> > but not one of the types already registered at IANA." >> > >> > >> > >> > Page 14, batteryMaxChargingCurrent (possible technical issue) >> > ------------------------------------------------------------- >> > >> > Between drafts -11 and -12, the battery capacity values were increased >> > in size from an Unsigned32 to an Unsigned64TC to accomodate very high >> > capacity batteries. >> > >> > For batteries with a capacity large enough to require an Unsigned64TC >> > is it sufficient to have a batteryMaxChargingCurrent limited to an >> > Unsigned32? >> > >> > For example, if a battery is ever built that has a capacity that must >> > be reported with the maximum value of the Unsigned64TC >> > batteryDesignCapacity, the maximum allowed charging current for that >> > battery might be too large to report with the Unsigned32 >> > batteryMaxChargingCurrent. >> > >> > >> > This same issue might apply to the batteryTrickleChargingCurrent MIB >> > object on Page 14, as well as the batteryActualCurrent MIB object on >> > Page 19. >> > >> > >> > Not sure what the best course of action is here. >>=20 >> We could do so, but then we have to change further objects related to >>The >> current including batteryActualCurrent which is a signed integer. >> We do not yet have a TC for Integer64. >>=20 >> > >> > Page 16, DESCRIPTION for batteryChargingCycleCount >> > -------------------------------------------------- >> > >> > The second paragraph of the DESCRIPTION for batteryChargingCycleCount >> > reads: >> > >> > "For batteries of type primary(1) the value of this object is >> > always 0." >> > >> > This enumeration name/number does not match the enumerated values >> > listed for the batteryType MIB object on page 12/13: >> > >> > batteryType OBJECT-TYPE >> > SYNTAX INTEGER { >> > unknown(1), >> > other(2), >> > primary(3), >> > rechargeable(4), >> > capacitor(5) >> > } >> > >> > Also, I think the charging cycle count only applies to a batteryType >> > of rechargeable(4), so would rewording this second paragraph make >> sense? >> > >> > "For batteries of any type other than rechargeable(4), the value of >> > this object is always 0." >> > >> > >> > >> > Page 17, DESCRIPTION for batteryChargingAdminState (nit) >> > -------------------------------------------------------- >> > >> > The first sentence of the first paragraph of the DESCRIPTION for >> > batteryChargingAdminState reads: >> > >> > "The value of this object indicates the desired status of >> > the charging state of the battery. >> > >> > Perhaps the following text is a little more concise: >> > >> > "The value of this object indicates the desired charging >> > state of the battery. >> > >> > >> > >> > Page 28, batteryTemperatureNotification (problem) >> > ------------------------------------------------- >> > >> > OBJECT batteryTemperatureNotification >> > MIN-ACCESS read-only >> > DESCRIPTION >> > "A compliant implementation is not required >> > to support set operations to this object." >> > >> > A MIB checker squawked about batteryTemperatureNotification is not >> > defined as an OBJECT-TYPE. >> > >> > >> > Should this be removed from the BATTERY-MIB? >>=20 >> Good catch: This should have been an object. >> I will replace batteryTemperatureNotification with >> batteryAlarmHighTemperature. >>=20 >> > >> > _______________________________________________ >> > eman mailing list >> > eman@ietf.org >> > https://www.ietf.org/mailman/listinfo/eman >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From nobody Thu Nov 6 11:26:05 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9791A8A69 for ; Thu, 6 Nov 2014 11:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.204 X-Spam-Level: * X-Spam-Status: No, score=1.204 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MANGLED_INCRS=2.3, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xik0cmu1HOX5 for ; Thu, 6 Nov 2014 11:26:02 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id ECABD1A8A68 for ; Thu, 6 Nov 2014 11:26:01 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA22051; Thu, 6 Nov 2014 14:25:58 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id sA6JPwXg015045; Thu, 6 Nov 2014 14:25:58 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id sA6JPw1L015044; Thu, 6 Nov 2014 14:25:58 -0500 (EST) (envelope-from luchuk) Date: Thu, 6 Nov 2014 14:25:58 -0500 (EST) From: Alan Luchuk Message-Id: <201411061925.sA6JPw1L015044@mainfs.snmp.com> To: , , "Alan Luchuk" In-Reply-To: Your message of Wed, 5 Nov 2014 10:18:22 +0000 <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd> References: <201403121757.NAA24671@adminfs.snmp.com> <9AB93E4127C26F4BA7829DEFDCE5A6E894C4AADA@PALLENE.office.hd> <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd> X-Mailer: mail (GNU Mailutils 2.2) Archived-At: http://mailarchive.ietf.org/arch/msg/eman/hltnx-4nnqbgbErGh66ZyDlAjNo Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-12 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2014 19:26:03 -0000 Hello, >From: Juergen Quittek >To: "eman@ietf.org" >CC: Alan Luchuk >Subject: RE: [eman] Comments on draft-ietf-eman-battery-mib-12 >Date: Wed, 5 Nov 2014 10:18:22 +0000 > 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header > > >The issues concerns the battery capacity for which we use an Unsigned64TC in order to be able to support batteries with more than 4MAh. The correct comment from Alan was that if we do so, we should for consistency also support corresponding 64-bit values for the objects we have concerning the electric current. For this we would need to introduce a new Signed64TC. This is all possible and no technical problem. > >However, I checked for existing battery sizes. It shows that all kinds of batteries that are used in electric vehicles or that you can by as energy storage for private households are well covered if we just use Unsigned32 for capacity values. If you go for industrial use, very large batteries are delivered in units of in 40-foot intermodal freight shipping containers. Even for the total capacity of such container, the Unsigned32 value would fit, although there would be not much headroom for further increa>ses of battery capacity per container. However, these containers are not organized as a "single" battery, but as an array of multiple batteries. And each individual one would be modeled as a separate row in the batteryTable of our MIB module. For the individual tables, I do not see a problem, with modeling them by Unsigned32 values. > >So, my proposal is removing the inconsistency addressed by Alan by reverting to Unsigned32 bit values for all objects related to battery capacity. +1 Seems like a reasonable solution to me also. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Mon Nov 17 11:34:04 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789201A000D; Mon, 17 Nov 2014 11:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih72VMq9p1CC; Mon, 17 Nov 2014 11:34:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFA41A005B; Mon, 17 Nov 2014 11:33:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141117193352.9513.24550.idtracker@ietfa.amsl.com> Date: Mon, 17 Nov 2014 11:33:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/Oz8YPBbWevxk2xVnBzsBc_ZBN2o Cc: eman@ietf.org Subject: [eman] Last Call: (Energy Management (EMAN) Applicability Statement) to Informational RFC X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:34:01 -0000 The IESG has received a request from the Energy Management WG (eman) to consider the following document: - 'Energy Management (EMAN) Applicability Statement' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Nov 27 13:25:20 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7C81A01F9; Thu, 27 Nov 2014 13:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiq_kKR3q_oa; Thu, 27 Nov 2014 13:25:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B711A0250; Thu, 27 Nov 2014 13:24:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141127212453.2546.16973.idtracker@ietfa.amsl.com> Date: Thu, 27 Nov 2014 13:24:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/kOacyucD4nEFkMiSzB0W6f2jwbQ Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-13.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 21:25:15 -0000 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 : Power, Energy Monitoring and Control MIB Authors : Mouli Chandramouli Benoit Claise Brad Schoening Juergen Quittek Thomas Dietz Filename : draft-ietf-eman-energy-monitoring-mib-13.txt Pages : 68 Date : 2014-11-27 Abstract: This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-energy-monitoring-mib-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 27 14:43:20 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520781A0222; Thu, 27 Nov 2014 14:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS4u9XONo8ll; Thu, 27 Nov 2014 14:43:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8281A01EA; Thu, 27 Nov 2014 14:43:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141127224314.1322.62669.idtracker@ietfa.amsl.com> Date: Thu, 27 Nov 2014 14:43:14 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/2owtccRTUQAheAJNiPxJR4xklTY Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-17.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 22:43:16 -0000 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 : Energy Object Context MIB Authors : John Parello Benoit Claise Mouli Chandramouli Filename : draft-ietf-eman-energy-aware-mib-17.txt Pages : 34 Date : 2014-11-27 Abstract: This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-energy-aware-mib-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Nov 29 20:04:49 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E3D1A017A; Sat, 29 Nov 2014 20:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvwAkpJ8o-lp; Sat, 29 Nov 2014 20:04:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D451A0162; Sat, 29 Nov 2014 20:04:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141130040438.19031.34475.idtracker@ietfa.amsl.com> Date: Sat, 29 Nov 2014 20:04:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/Xpfy9W2rKAxPbXS33veheqWTTCM Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-battery-mib-13.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 04:04:45 -0000 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 Authors : Juergen Quittek Rolf Winter Thomas Dietz Filename : draft-ietf-eman-battery-mib-13.txt Pages : 36 Date : 2014-11-29 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-battery-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-battery-mib-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-battery-mib-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/