From Thomas.Dietz@neclab.eu Mon Feb 3 05:47: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 4B4951A0415 for ; Mon, 3 Feb 2014 05:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTYPE_001C_B=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, 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 bc4vdlAxwCqw for ; Mon, 3 Feb 2014 05:47:44 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 76A6C1ADE8A for ; Mon, 3 Feb 2014 05:30:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 40FC4106B23; Mon, 3 Feb 2014 14:30:44 +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 ZQ+xpiGxIARt; Mon, 3 Feb 2014 14:30:44 +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 1556A106B05; Mon, 3 Feb 2014 14:30:29 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 3 Feb 2014 14:30:28 +0100 From: Thomas Dietz To: Brad Schoening , Bruce Nordman , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvOnytsgxxDl0udfN1WluowmJqdedQAgAAhIACAAADCgIAAHh+AgAAKQgCAALb5sIAAc8OAgAScnCA= Date: Mon, 3 Feb 2014 13:30:28 +0000 Message-ID: <75581E268A48F849916117B977D76D37688A7A30@DAPHNIS.office.hd> References: <75581E268A48F849916117B977D76D37688A1886@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.117] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CF20EC.7B879ED0" MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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: Mon, 03 Feb 2014 13:47:49 -0000 ------=_NextPart_000_0000_01CF20EC.7B879ED0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01CF20EC.7B879ED0" ------=_NextPart_001_0001_01CF20EC.7B879ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brad, =20 You tend to put all those elements that put some structure (except the domain) into the keywords. Those keywords need to be parsed by the Management System and does complicate building some more structure into these objects. Usually the world is more complex than putting one thing exactly to one domain all the time. In addition putting structure to keywords makes filtering in advance for those objects that the = Management System wants to act on more complex because it first needs to read all keywords for all objects, parse them and filter out those that it does = not need right now. =20 If I would play devil=92s advocate why not put the domain into the = keywords as well? =20 Best Regards, =20 Thomas =20 --=20 Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany =20 NEC Europe Limited, Registered in England 2832014 Registered Office: Athene, Odyssey Business Park, West End Road, = London, HA4 6QE, GB =20 From: Brad Schoening [mailto:brads@coraid.com]=20 Sent: Friday, January 31, 2014 4:57 PM To: Thomas Dietz; Bruce Nordman; eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 =20 HI Thomas, =20 As Mouli mentioned in a separate email, the use case you mention can be address with keywords. A single domain + keywords gives flexibility in characterizing your environment. Given this, I think the current single domain model has shown it address all the specific concerns raised thus far. =20 Best Regards, =20 Brad =20 Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com=20 Coraid: Redefining Storage =20 =20 From: Thomas Dietz > Date: Fri, 31 Jan 2014 08:15:36 +0000 To: Brad Schoening >, Bruce Nordman >, eman mailing list > Subject: RE: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 =20 Dear Brad, all, =20 first of all I second J=FCrgen=92s view that we should not artificially = limit ourselves if there is no technical reason. =20 And what the discussion below shows is exactly the reason for that. The definition of the domain leaves some room for interpretation. Thus, IMHO = it should be allowed to have an implementation of a domain that allows that objects are part of more than one domain. You could define the domain as = a sort of =93geographical domain=94 and have a building that get = controlled by the owner and some rental units that are controlled by the tenant. This = would imply that the same object are part of two different domain. And this example would match in my opinion the definition of domain in the = framework document. =20 Best Regards, =20 Thomas =20 --=20 Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany =20 NEC Europe Limited, Registered in England 2832014 Registered Office: Athene, Odyssey Business Park, West End Road, = London, HA4 6QE, GB =20 From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Brad Schoening Sent: Thursday, January 30, 2014 11:08 PM To: Bruce Nordman; eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 =20 "If one uses domain in the recommended fashion, then a device that = receives power from two sources (each sub-metered) is definitely in two different domains." =20 Or a new domain, which combines the two and has its own power policy. = In which case, a single domain suits our model quite well. =20 Regards, =20 Brad =20 From: Bruce Nordman > Date: Thu, 30 Jan 2014 13:31:11 -0800 To: eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 =20 For the Domain issue, I have always believed that the Framework draft did not define the concept well. Since it is ambiguous in the = Framework, it is not surprising that we are running into problems with it in later stages (the MIBs for example). The current Framework states (6.3.6): An Energy Management Domain can be any collection of Energy Objects in a deployment, but it is recommended to map 1:1 with a metered or sub-metered portion of the site. If one uses domain in the recommended fashion, then a device that = receives power from two sources (each sub-metered) is definitely in two different domains. If one uses it differently, as is permitted, then many reasonable and useful usages require more than one domain. Another way to think about this is that it was a flawed idea in the first place that a device is in a domain at all. It is the power interface (or interfaces, for devices which receive supply from more than one) that is in the domain, not the device itself. An interface is more clearly in one domain. Different types of entities (devices, components, power interfaces) have different types of data available, so having domain only in the PI is quite reasonable. Thus, the correct answer to me for domain for a device is either zero or multiple. To recommend one as a compromise seeks OK. For a PI, only a single domain is needed. I second Juergen's line of reasoning that it is quite unnecessary and not justified to make the framework change to single at this time. Thanks, --Bruce --=20 Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov =20 BNordman@LBL.gov =20 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman=20 ------=_NextPart_001_0001_01CF20EC.7B879ED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Brad,

 

You tend to put all those elements that put some structure (except = the domain) into the keywords. Those keywords need to be parsed by the = Management System and does complicate building some more structure into = these objects. Usually the world is more complex than putting one thing = exactly to one domain all the time. In addition putting structure to = keywords makes filtering in advance for those objects that the = Management System wants to act on more complex because it first needs to = read all keywords for all objects, parse them and filter out those that = it does not need right now.

 

If I would play devil’s advocate why not put the domain into = the keywords as well?

 

Best Regards,

 

Thomas

 

--

Thomas Dietz

NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 = Heidelberg, Germany

 

NEC Europe Limited, Registered in England = 2832014

Registered Office: Athene, Odyssey Business Park, West End =  Road, London, HA4 6QE, GB

 

From: Brad = Schoening [mailto:brads@coraid.com]
Sent: Friday, January 31, = 2014 4:57 PM
To: Thomas Dietz; Bruce Nordman; eman mailing = list
Subject: Re: [eman] WG Last Call for = draft-ietf-eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13

 

HI Thomas,

 

As Mouli mentioned in a separate email, the use case you mention can be = address with keywords.  A single domain + keywords gives = flexibility in characterizing your environment.  Given this, I = think the current single domain model has shown it address all the = specific concerns raised  thus = far.

 

Best Regards,

 

Brad

 

= Brad Schoening=
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com

= Coraid: Redefining Storage

 

 

From: Thomas Dietz <Thomas.Dietz@neclab.eu>
= Date: Fri, 31 Jan 2014 08:15:36 +0000
To: Brad = Schoening <brads@coraid.com>, Bruce Nordman = <bnordman@lbl.gov>, eman = mailing list <eman@ietf.org>
Subject: = RE: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 = and = draft-ietf-eman-energy-aware-mib-13

 

Dear Brad, all,

 

first of all I second J=FCrgen’s view that we should not = artificially limit ourselves if there is no technical = reason.

 

And what the discussion below shows is exactly the reason for that. = The definition of the domain leaves some room for interpretation. Thus, = IMHO it should be allowed to have an implementation of a domain that = allows that objects are part of more than one domain. You could define = the domain as a sort of “geographical domain” and have a = building that get controlled by the owner and some rental units that are = controlled by the tenant. This would imply that the same object are part = of two different domain. And this example would match in my opinion the = definition of domain in the framework document.

 

Best Regards,

 

Thomas

 

--

Thomas Dietz

NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 = Heidelberg, Germany

 

NEC Europe Limited, Registered in England 2832014

Registered Office: Athene, Odyssey Business Park, West End =  Road, London, HA4 6QE, GB

 

From: eman [mailto:eman-bounces@ietf.org] = On Behalf Of Brad Schoening
Sent: Thursday, January 30, = 2014 11:08 PM
To: Bruce Nordman; eman mailing = list
Subject: Re: [eman] WG Last Call for = draft-ietf-eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13

 

"If one uses domain in the recommended fashion, then a device that = receives

power from two sources (each sub-metered) is definitely in two = different

domains."

 

Or a new domain, which combines the two and has its own power policy. =  In which case, a single domain suits our model quite = well.

 

Regards,

 

Brad

 

From: Bruce Nordman <bnordman@lbl.gov>
Date: = Thu, 30 Jan 2014 13:31:11 -0800
To: eman mailing list = <eman@ietf.org>
Subject: = Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 = and draft-ietf-eman-energy-aware-mib-13

 

For the Domain issue, I have always believed that the Framework = draft
did not define the concept well.  Since it is ambiguous in = the Framework,
it is not surprising that we are running into problems = with it in later
stages (the MIBs for example).

The current = Framework states (6.3.6):

   An Energy Management = Domain can be any collection of Energy
   Objects in a = deployment, but it is recommended to map 1:1
   with a = metered or sub-metered portion of the site.

If one uses domain in = the recommended fashion, then a device that receives
power from two = sources (each sub-metered) is definitely in two = different
domains.
If one uses it differently, as is permitted, = then many reasonable
and useful usages require more than one = domain.

Another way to think about this is that it was a flawed = idea in
the first place that a device is in a domain at all.  It = is the
power interface (or interfaces, for devices which receive = supply
from more than one) that is in the domain, not the device = itself.
An interface is more clearly in one domain.  Different = types of
entities (devices, components, power interfaces) have = different
types of data available, so having domain only in the PI is = quite
reasonable.

Thus, the correct answer to me for domain = for a device is either
zero or multiple.  To recommend one as a = compromise seeks OK.
For a PI, only a single domain is = needed.

I second Juergen's line of reasoning that it is quite = unnecessary
and not justified to make the framework change to single = at this time.

Thanks,

--Bruce

--

Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
= m: 510-501-7943

_______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/= mailman/listinfo/eman

------=_NextPart_001_0001_01CF20EC.7B879ED0-- ------=_NextPart_000_0000_01CF20EC.7B879ED0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFXTCCBEWgAwIBAgIHFXEjuSzkIzANBgkqhkiG9w0BAQUFADCBkDELMAkG A1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRv cmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMzAzMjYxMzQ0MDlaFw0xNjAzMjUxMzQ0MDla MGAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBM YWJvcmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCpjbFMyLnXM7ssr9eAuoFSJd2fNyleLDl+BbAd4uaSuD6IacC4Cq/d e3tXtiuM1o5HefxvXMcgRArYdmhICR+Il4jJwHOcZyfKzlBbqtQrzUgbixiuqhDNCmhxoLMRTJtY aDIuoRqVXzqDjU1gWB+BAKIA2B7KzCCZtGnmd2QSAmZkSPL3X+FMQ64+5cTPijzOJ5dgX5mAdHX2 /OUWZ12NdrspIoxoKx3twk9tRVv9K30ehOFN7BV1aJfjEiEWCOGT5aE6dxle+ujn+U/TG8GIyfE6 uXCituRUM168X6CfzoSM8rE8bjXzTiy92bPtQmXIgW9Jn5sE+/hn7yV5BNIpAgMBAAGjggHpMIIB 5TAvBgNVHSAEKDAmMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAgEEAwAwCQYDVR0T BAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBSfxN6vdKpCh8VajmMo3lQw21coTDAfBgNVHSMEGDAWgBRPHId6HeAvmfa+FarRNZ0OSua6NjAh BgNVHREEGjAYgRZUaG9tYXMuRGlldHpAbmVjbGFiLmV1MH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDigNqA0hjJodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY3JsL2NhY3JsLmNybDCBmAYIKwYBBQUH AQEEgYswgYgwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDIucGNhLmRmbi5kZS9u ZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBeQruB47uM aISTpyfmtUw9p5FwiQJ6voD76MjHdSP5eR2Li/h/N1HQKi417Wztz55iI2H5Jywi38aIoYKDkByw NHZPgOgPcEBUG6p7vrbMaxFZrZvOWAm471kFgHnL+CeX80xujmfuxT2GnULYmq1KQaGzqWvXAgms mopuKE4D+O4tIhlPr9mmdBClrJ2vfwGfR0wf94LoA1SRYatmrpp7yrpWSQHYYcZ2dVF6HBVIGp14 rZW/tw9jKxoX39yoGOxRR60kew/58wPmS+O8BzvG0n9mAOwCmd8ZhiKrW18GZpJ0+TNi9zc+MJcv TFQS3SzT4qpe1BdI9bB+BoU8q7irMYIENTCCBDECAQEwgZwwgZAxCzAJBgNVBAYTAkRFMRgwFgYD VQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIw EAYDVQQDEwlORUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBu dy5uZWNsYWIuZXUCBxVxI7ks5CMwCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjAzMTMzMDI3WjAjBgkqhkiG9w0BCQQxFgQU26BXzO0r OMBRgejXDYd2eSi+g5QwgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwga0GCSsGAQQBgjcQBDGBnzCBnDCBkDELMAkGA1UEBhMCREUxGDAW BgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBFdXJvcGUx EjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1bmdzc3RlbGxl QG53Lm5lY2xhYi5ldQIHFXEjuSzkIzCBrwYLKoZIhvcNAQkQAgsxgZ+ggZwwgZAxCzAJBgNVBAYT AkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMg RXVyb3BlMRIwEAYDVQQDEwlORUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5n c3N0ZWxsZUBudy5uZWNsYWIuZXUCBxVxI7ks5CMwDQYJKoZIhvcNAQEBBQAEggEAnkm3gpm2no0f xfQVXYAKO+W1ZytH0RJ+E1Rzl5GikD9tkTh0xthc6Fphvh9Cw9/FxbeFV8UPTylwP0jFvZPdTUWS zuB4CRcUlLLUM8jhIJk5P00nJyczJnK3xEglehULrPaU4O6mvCo/Q75gIEecVYHRE0eR2F9IrY/E Q/XXk4EbIjouXqCNOFztWlDtBnhjP/vjBaBuYzAfz2fc1kLVSJlxpzMOAp+w4bh5qDp+j7xP1J1G LleMqm7M4CNNOhVi8v79dRywcLOLN/5XitcI6G7BHiBzMflxfJsmQ+0tVruEGgtQyrwykvoOw7O7 9LT4Yfy8NHFbCZ2Zf17I8NM0aQAAAAAAAA== ------=_NextPart_000_0000_01CF20EC.7B879ED0-- From brads@coraid.com Mon Feb 3 07:32:18 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 260681A00DC for ; Mon, 3 Feb 2014 07:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 Au7_Fn9AsNul for ; Mon, 3 Feb 2014 07:32:14 -0800 (PST) Received: from server506.appriver.com (server506c.appriver.com [50.56.144.127]) by ietfa.amsl.com (Postfix) with ESMTP id 662771A00E1 for ; Mon, 3 Feb 2014 07:32:14 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/3/2014 9:32:13 AM X-Policy: GLOBAL - coraid.com 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-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-270/SG:5 2/3/2014 9:31:17 AM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.964134 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.2054 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 2/3/2014 9:32:06 AM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: smtp.exg6.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 50794037; Mon, 03 Feb 2014 09:32:13 -0600 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT03-E6.exg6.exghost.com ([50.56.144.21]) with mapi id 14.03.0158.001; Mon, 3 Feb 2014 09:32:13 -0600 From: Brad Schoening To: Thomas Dietz , Bruce Nordman , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPG+0tpS6rr1XnlUCE8LfKL9ID95qaoPaAgAIjFICAAKfBAIAApz8AgAAAwoCAAB4fgP//hCMAgAEv6QD///rTAIAFFCUA///OLYA= Date: Mon, 3 Feb 2014 15:32:11 +0000 Message-ID: In-Reply-To: <75581E268A48F849916117B977D76D37688A7A30@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.56.144.245] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_CF1515A51136C5bradscoraidcom_" MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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: Mon, 03 Feb 2014 15:32:18 -0000 --_000_CF1515A51136C5bradscoraidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thomas, The power domain provides a first-order grouping. The keywords and relatio= nships in EMAN-Energy-Aware-MIB provide for additional characterization tha= t allow you to "slice and dice" your energy objects in context specific way= s (such as the landlord =96 tenant relationship you mentioned). Sec 5.2 of the Energy-Aware-MIB states: An Energy Object can provide a set of eoKeywords. These keywords are a list of tags that can be used for grouping and summary reporting within or between Energy Management Domains. You ask: "why not put the domain into the keywords as well"? Well, because= having a first order grouping into a single domain is both useful and prac= tical. It tends to closely match the physical distribution of power, while= the keywords allow for additional levels of grouping when and if required.= This minimizes the parsing you would need to do in simple use cases. The discussion has been a useful exercise to validate that the existing mod= el works well to address the use cases you and Juergen have raised. As Ben= oit notes, implementation experience over the last 6 years has also verifie= d the usability of this approach. Regards, Brad From: Thomas Dietz > Date: Mon, 3 Feb 2014 13:30:28 +0000 To: Brad Schoening >, Bruce Nordm= an >, eman mailing list > Subject: RE: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 Hi Brad, You tend to put all those elements that put some structure (except the doma= in) into the keywords. Those keywords need to be parsed by the Management S= ystem and does complicate building some more structure into these objects. = Usually the world is more complex than putting one thing exactly to one dom= ain all the time. In addition putting structure to keywords makes filtering= in advance for those objects that the Management System wants to act on mo= re complex because it first needs to read all keywords for all objects, par= se them and filter out those that it does not need right now. If I would play devil=92s advocate why not put the domain into the keywords= as well? Best Regards, Thomas -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelb= erg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: Athene, Odyssey Business Park, West End Road, London, H= A4 6QE, GB From: Brad Schoening [mailto:brads@coraid.com] Sent: Friday, January 31, 2014 4:57 PM To: Thomas Dietz; Bruce Nordman; eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 HI Thomas, As Mouli mentioned in a separate email, the use case you mention can be add= ress with keywords. A single domain + keywords gives flexibility in charac= terizing your environment. Given this, I think the current single domain m= odel has shown it address all the specific concerns raised thus far. Best Regards, Brad Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Thomas Dietz > Date: Fri, 31 Jan 2014 08:15:36 +0000 To: Brad Schoening >, Bruce Nordm= an >, eman mailing list > Subject: RE: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 Dear Brad, all, first of all I second J=FCrgen=92s view that we should not artificially lim= it ourselves if there is no technical reason. And what the discussion below shows is exactly the reason for that. The def= inition of the domain leaves some room for interpretation. Thus, IMHO it sh= ould be allowed to have an implementation of a domain that allows that obje= cts are part of more than one domain. You could define the domain as a sort= of =93geographical domain=94 and have a building that get controlled by th= e owner and some rental units that are controlled by the tenant. This would= imply that the same object are part of two different domain. And this exam= ple would match in my opinion the definition of domain in the framework doc= ument. Best Regards, Thomas -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelb= erg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: Athene, Odyssey Business Park, West End Road, London, H= A4 6QE, GB From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Brad Schoening Sent: Thursday, January 30, 2014 11:08 PM To: Bruce Nordman; eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 "If one uses domain in the recommended fashion, then a device that receives power from two sources (each sub-metered) is definitely in two different domains." Or a new domain, which combines the two and has its own power policy. In w= hich case, a single domain suits our model quite well. Regards, Brad From: Bruce Nordman > Date: Thu, 30 Jan 2014 13:31:11 -0800 To: eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 For the Domain issue, I have always believed that the Framework draft did not define the concept well. Since it is ambiguous in the Framework, it is not surprising that we are running into problems with it in later stages (the MIBs for example). The current Framework states (6.3.6): An Energy Management Domain can be any collection of Energy Objects in a deployment, but it is recommended to map 1:1 with a metered or sub-metered portion of the site. If one uses domain in the recommended fashion, then a device that receives power from two sources (each sub-metered) is definitely in two different domains. If one uses it differently, as is permitted, then many reasonable and useful usages require more than one domain. Another way to think about this is that it was a flawed idea in the first place that a device is in a domain at all. It is the power interface (or interfaces, for devices which receive supply from more than one) that is in the domain, not the device itself. An interface is more clearly in one domain. Different types of entities (devices, components, power interfaces) have different types of data available, so having domain only in the PI is quite reasonable. Thus, the correct answer to me for domain for a device is either zero or multiple. To recommend one as a compromise seeks OK. For a PI, only a single domain is needed. I second Juergen's line of reasoning that it is quite unnecessary and not justified to make the framework change to single at this time. Thanks, --Bruce -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_CF1515A51136C5bradscoraidcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thomas,

The power domain provides a first-orde= r grouping.  The keywords and relationships in EMAN-Energy-Aware-MIB p= rovide for additional characterization that allow you to "slice and di= ce" your energy objects in context specific ways (such as the landlord =96 tenant relationship you mentioned).  <= /div>

Sec 5.2 of the Energy-Aware-MIB states= :

        An Energy Object can provide =
a set of eoKeywords. These keywords
        are a list of tags that can be used for grouping and summary
        reporting within or between Energy Management Domains.
You ask: "why not put the domain = into the keywords as well"?  Well, because having a first order g= rouping into a single domain is both useful and practical.  It tends t= o closely match the physical distribution of power, while the keywords allow for additional levels of grouping when and if required.=  This minimizes the parsing you would need to do in simple use cases.=

The discussion has been a useful exerc= ise to validate that the existing model works well to address the use cases= you and Juergen have raised.  As Benoit notes, implementation experie= nce over the last 6 years has also verified the usability of this approach. 

Regards,

Brad


From: Thomas Dietz <Thomas.Dietz@neclab.eu>
Date: Mon, 3 Feb 2014 13:30:28 += ;0000
To: Brad Schoening <brads@coraid.com>, Bruce Nordman <bnordman@lbl.gov>, eman mailing list &l= t;eman@ietf.org>
Subject: RE: [eman] WG Last Call fo= r draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware= -mib-13

Hi Brad,

 

You tend to put all those elements= that put some structure (except the domain) into the keywords. Those keywo= rds need to be parsed by the Management System and does complicate building some more structure into these objects= . Usually the world is more complex than putting one thing exactly to one d= omain all the time. In addition putting structure to keywords makes filteri= ng in advance for those objects that the Management System wants to act on more complex because it first n= eeds to read all keywords for all objects, parse them and filter out those = that it does not need right now.

 

If I would play devil=92s advocate= why not put the domain into the keywords as well?

 

Best Regards,

 

Thomas

 

--

Thomas Dietz

NEC Europe Ltd., NEC Laboratories,= Network Research Division, 69115 Heidelberg, Germany

 

NEC Europe Limited, Registered in = England 2832014

Registered Office: Athene, Odyssey= Business Park, West End  Road, London, HA4 6QE, GB<= /p>

 

From: Brad Schoening [mailto:brads@coraid.com]
Sent: Friday, January 31, 2014 4:57 PM
To: Thomas Dietz; Bruce Nordman; eman mailing list
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitori= ng-mib-08 and draft-ietf-eman-energy-aware-mib-13

 

HI Thomas,

 

As Mouli mentioned in a separate email, the= use case you mention can be address with keywords.  A single domain &= #43; keywords gives flexibility in characterizing your environment.  Given this, I think the current single domain mode= l has shown it address all the specific concerns raised  thus far.

 

Best Regards,

 

Brad

 

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com

Coraid: Redefining Storage

 

 

From: Thomas Dietz <Thomas.Dietz@neclab.eu>
Date: Fri, 31 Jan 2014 08:15:36 +0000
To: Brad Schoening <brads@cor= aid.com>, Bruce Nordman <bnor= dman@lbl.gov>, eman mailing list <eman@ietf.org>
Subject: RE: [eman] WG Last Call for draft-ietf-eman-energy-monitori= ng-mib-08 and draft-ietf-eman-energy-aware-mib-13

 

Dear Brad, all,

 

first of all I second J=FCrgen=92s= view that we should not artificially limit ourselves if there is no techni= cal reason.

 

And what the discussion below show= s is exactly the reason for that. The definition of the domain leaves some = room for interpretation. Thus, IMHO it should be allowed to have an implementation of a domain that allows tha= t objects are part of more than one domain. You could define the domain as = a sort of =93geographical domain=94 and have a building that get controlled= by the owner and some rental units that are controlled by the tenant. This would imply that the same object a= re part of two different domain. And this example would match in my opinion= the definition of domain in the framework document.

 

Best Regards,

 

Thomas

 

--

Thomas Dietz

NEC Europe Ltd., NEC Laboratories,= Network Research Division, 69115 Heidelberg, Germany

 

NEC Europe Limited, Registered in = England 2832014

Registered Office: Athene, Odyssey= Business Park, West End  Road, London, HA4 6QE, GB

 

From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Brad Schoening
Sent: Thursday, January 30, 2014 11:08 PM
To: Bruce Nordman; eman mailing list
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitori= ng-mib-08 and draft-ietf-eman-energy-aware-mib-13

 =

"If one uses domain in the recommended= fashion, then a device that receives

power from two sources (each sub-metered) i= s definitely in two different=

domains."

 

Or a new domain, which combines the two and= has its own power policy.  In which case, a single domain suits our m= odel quite well.

 

Regards,=

 

Brad

 

From: Bruce Nordman <bno= rdman@lbl.gov>
Date: Thu, 30 Jan 2014 13:31:11 -0800
To: eman mailing list <eman@ietf= .org>
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitori= ng-mib-08 and draft-ietf-eman-energy-aware-mib-13

 

For the Domain issue, I have always believe= d that the Framework draft
did not define the concept well.  Since it is ambiguous in the Framewo= rk,
it is not surprising that we are running into problems with it in later
stages (the MIBs for example).

The current Framework states (6.3.6):

   An Energy Management Domain can be any collection of Energy    Objects in a deployment, but it is recommended to map 1:1
   with a metered or sub-metered portion of the site.

If one uses domain in the recommended fashion, then a device that receives<= br> power from two sources (each sub-metered) is definitely in two different domains.
If one uses it differently, as is permitted, then many reasonable
and useful usages require more than one domain.

Another way to think about this is that it was a flawed idea in
the first place that a device is in a domain at all.  It is the
power interface (or interfaces, for devices which receive supply
from more than one) that is in the domain, not the device itself.
An interface is more clearly in one domain.  Different types of
entities (devices, components, power interfaces) have different
types of data available, so having domain only in the PI is quite
reasonable.

Thus, the correct answer to me for domain for a device is either
zero or multiple.  To recommend one as a compromise seeks OK.
For a PI, only a single domain is needed.

I second Juergen's line of reasoning that it is quite unnecessary
and not justified to make the framework change to single at this time.

Thanks,

--Bruce

--

Bruce Nordman
Lawrence Berkeley National Laboratorynordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

___________________________________________= ____ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman

--_000_CF1515A51136C5bradscoraidcom_-- From n.brownlee@auckland.ac.nz Mon Feb 3 14:14: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 5446E1A01EE for ; Mon, 3 Feb 2014 14:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 od2qmUwYqoCL for ; Mon, 3 Feb 2014 14:14:02 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B6AA11A015D for ; Mon, 3 Feb 2014 14:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1391465642; x=1423001642; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=95dMF2WzdzkUFL+ip/1/bTLRsossPp95+yw40FNyAfw=; b=gAewLY9LWRH5TV9qC4QQoxrE7EZPsqNiv+W/pQ8JAvtyCZ/AVDOLAUQB 0Isd50xM3EtmoDXn9ag0NV2bEakFRGBXstsI5uH+pcbHDAL7VoSRS4kRo my79c6kqkzVfsf0O3feOYJvpyGdLVyHdtHsJX+CZScCWN3qElJeGD18Lt k=; X-IronPort-AV: E=Sophos;i="4.95,774,1384254000"; d="scan'208";a="232611776" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 04 Feb 2014 11:14:01 +1300 Message-ID: <52F014A7.7040901@auckland.ac.nz> Date: Tue, 04 Feb 2014 11:13:59 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: draft-ietf-eman-framework@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "eman@ietf.org" Subject: [eman] Mail regarding draft-ietf-eman-framework 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: Mon, 03 Feb 2014 22:14:04 -0000 Hi Framework authors: Your WG co-chairs have considered the 11.45th-hour discussion on MUST vs SHOULD for energy management domains. We believe that making this change will - effectively - "fix a typo? in the framework draft. Please publish a new version, with that change. Thanks to all who contributed to this discussion. Cheers, Nevil & Tom -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From joelja@bogus.com Mon Feb 3 15:35:13 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 7B0331A026A for ; Mon, 3 Feb 2014 15:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 yH8ntinKcLJp for ; Mon, 3 Feb 2014 15:35:11 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C1A881A0268 for ; Mon, 3 Feb 2014 15:35:11 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s13NZ5eh005869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Feb 2014 23:35:06 GMT (envelope-from joelja@bogus.com) Message-ID: <52F027A3.3030903@bogus.com> Date: Mon, 03 Feb 2014 15:34:59 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Nevil Brownlee , draft-ietf-eman-framework@tools.ietf.org References: <52F014A7.7040901@auckland.ac.nz> In-Reply-To: <52F014A7.7040901@auckland.ac.nz> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qJ1OdndXDc7kSI8wv0MljsslIsdsdmI82" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 03 Feb 2014 23:35:07 +0000 (UTC) Cc: "eman@ietf.org" Subject: Re: [eman] Mail regarding draft-ietf-eman-framework 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: Mon, 03 Feb 2014 23:35:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qJ1OdndXDc7kSI8wv0MljsslIsdsdmI82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/3/14, 2:13 PM, Nevil Brownlee wrote: >=20 > Hi Framework authors: >=20 > Your WG co-chairs have considered the 11.45th-hour discussion on > MUST vs SHOULD for energy management domains. >=20 > We believe that making this change will - effectively - "fix a > typo? in the framework draft. Please publish a new version, > with that change. >=20 > Thanks to all who contributed to this discussion. Thank you. joel > Cheers, Nevil & Tom >=20 --qJ1OdndXDc7kSI8wv0MljsslIsdsdmI82 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLwJ6MACgkQ8AA1q7Z/VrJhhACfRREqZYju1A41Mxema0uRy4BK V3oAn22I1dJIyMNPF04/23PKuMTGnAok =jJvH -----END PGP SIGNATURE----- --qJ1OdndXDc7kSI8wv0MljsslIsdsdmI82-- From internet-drafts@ietf.org Mon Feb 3 20:29:11 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 5E56F1A01C2; Mon, 3 Feb 2014 20:29:11 -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 lY-ta-vHyRAg; Mon, 3 Feb 2014 20:29:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F26081A0366; Mon, 3 Feb 2014 20:29:08 -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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204042908.21053.17747.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2014 20:29:08 -0800 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-framework-15.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: Tue, 04 Feb 2014 04:29:11 -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 Management Framework Authors : Benoit Claise Brad Schoening Juergen Quittek Filename : draft-ietf-eman-framework-15.txt Pages : 57 Date : 2014-02-03 Abstract: This document defines a framework for Energy Management for devices and device components within or connected to communication networks. The framework presents a physical reference model and information model. The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally the framework models relationships and capabilities between Energy Objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-framework-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-framework-15 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 Quittek@neclab.eu Tue Feb 4 00:44:29 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 5CD071A03A1 for ; Tue, 4 Feb 2014 00:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, 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 CvxHWeNQY33S for ; Tue, 4 Feb 2014 00:44:27 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB991A039E for ; Tue, 4 Feb 2014 00:44:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8EB56106B44; Tue, 4 Feb 2014 09:44:26 +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 b1nNi0mNnIP1; Tue, 4 Feb 2014 09:44:25 +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 C23DB106B43; Tue, 4 Feb 2014 09:44:10 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 4 Feb 2014 09:43:49 +0100 From: Juergen Quittek To: Nevil Brownlee , "draft-ietf-eman-framework@tools.ietf.org" Thread-Topic: [eman] Mail regarding draft-ietf-eman-framework Thread-Index: AQHPIS1NGviFhwgvt06S83Utehpo65qkxgYg Date: Tue, 4 Feb 2014 08:43:49 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E868918B50@DAPHNIS.office.hd> References: <52F014A7.7040901@auckland.ac.nz> In-Reply-To: <52F014A7.7040901@auckland.ac.nz> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] Mail regarding draft-ietf-eman-framework 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: Tue, 04 Feb 2014 08:44:29 -0000 Dear Nevil, I accept your decision as eman co-chair. However,=20 I challenge your statement that "SHOULD" vs. "MUST" is a typo. This decision has still been made with NO technical reason for the MUST,=20 but WITH technical reasons against the MUST. I do not see clear consensus on this decision in the WG and=20 request to have this reflected in the write-up for the framework draft.=20 Cheers, Juergen > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Nevil Brownlee > Sent: Montag, 3. Februar 2014 23:14 > To: draft-ietf-eman-framework@tools.ietf.org > Cc: eman@ietf.org > Subject: [eman] Mail regarding draft-ietf-eman-framework >=20 >=20 > Hi Framework authors: >=20 > Your WG co-chairs have considered the 11.45th-hour discussion on MUST vs > SHOULD for energy management domains. >=20 > We believe that making this change will - effectively - "fix a typo? in t= he > framework draft. Please publish a new version, with that change. >=20 > Thanks to all who contributed to this discussion. >=20 > Cheers, Nevil & Tom >=20 > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From Quittek@neclab.eu Tue Feb 4 04:18:42 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 8326A1A0383 for ; Tue, 4 Feb 2014 04:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, 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 KDdSGdK4gVHt for ; Tue, 4 Feb 2014 04:18:39 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1AF1A03A9 for ; Tue, 4 Feb 2014 04:18:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7A03D106B21; Tue, 4 Feb 2014 13:18:34 +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 ikjgP8TTHSdq; Tue, 4 Feb 2014 13:18:34 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 5E3A4106B42; Tue, 4 Feb 2014 13:18:19 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 4 Feb 2014 13:18:19 +0100 From: Juergen Quittek To: Brad Schoening , Thomas Nadeau , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHDodmAOXF01vlk+Ral4ysbWZOpqcRqCwgAE1VwCAB5BnEA== Date: Tue, 4 Feb 2014 12:18:18 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E868918F95@DAPHNIS.office.hd> References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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: Tue, 04 Feb 2014 12:18:42 -0000 Hi Brad, I am much in line with what you write. If a dual-supplied server receives power from two metering domains "supplyA= " and "supplyB", then we can claim this server to be member of domain "supp= lyA,supplyB". A management system that supports only one domain per device = would create a new domain called "supplyA,supplyB" (very similar to what yo= u suggested, while a management system supporting multiple domains would mo= del the server as a device with two memberships, one in domain "supplyA" an= d one in domain "supplyB". Cheers, Juergen > -----Original Message----- > From: Brad Schoening [mailto:brads@coraid.com] > Sent: Donnerstag, 30. Januar 2014 18:42 > To: Juergen Quittek; Thomas Nadeau; eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring- > mib-08 and draft-ietf-eman-energy-aware-mib-13 >=20 > Juergen, >=20 > In your dual power supply example, I would think of these as three > domains: supplyA, supplyB and supplyAB. The new domain supplyAB is a > high-reliabliy domain. You don't mention what the power policy of this n= ew > combined domain is, but there could be several choices for supplyAB. >=20 > Consider a more complicated example, you have a chassis with three power > supply modules. There are at least three different policies that could b= e > applied: >=20 > - Power module redundancy - total power allowed is one less than the > number of supply modules > E.g., total power is 2 x. >=20 > - Power module redundancy with throttling - total power allowed is equal = to > available power, but > requires consumers to throttle down if one module fails. E.g., total p= ower is > between 2x and 3x. >=20 > - Basic power w/o redundancy - total power allowed is equal to all availa= ble > power with no redundancy. E.g., total power is 3x. >=20 > Combining power domains likely always invokes a policy and thus in the > eman model, creates a new domain. >=20 > This approach is compatible with the chairs suggestion of MUST. >=20 > Regards, >=20 >=20 > Brad >=20 > On 1/29/14 3:41 PM, "Juergen Quittek" wrote: >=20 > >1. Having a device limited to a single domain membership is a > >limitation/feature of Cisco's EnergyWise for which in all the long > >discussions we had in past year never any technical reason was given > >(although it was asked for multiple times). In the contrary, I gave use > >cases where it is REQUIRED to have two or more domains. An obvious > >example is a highly reliable server that has dual power supply. Its two > >power supply lines SHOULD be in different domains in order to be better > >protected from local power supply failures. This server should be given > >means to report via the MIB that it is member of two domains. From tnadeau@lucidvision.com Tue Feb 4 05:58:17 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 359CB1A011C for ; Tue, 4 Feb 2014 05:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 8yJ9lZprv10Y for ; Tue, 4 Feb 2014 05:58:15 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 267CC1A00E4 for ; Tue, 4 Feb 2014 05:58:14 -0800 (PST) Received: from [10.9.247.162] (mobile-166-137-187-011.mycingular.net [166.137.187.11]) by lucidvision.com (Postfix) with ESMTP id E802626DB9E4; Tue, 4 Feb 2014 08:58:13 -0500 (EST) References: <52F014A7.7040901@auckland.ac.nz> <9AB93E4127C26F4BA7829DEFDCE5A6E868918B50@DAPHNIS.office.hd> Mime-Version: 1.0 (1.0) In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E868918B50@DAPHNIS.office.hd> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B554a) From: "Thomas D. Nadeau" Date: Tue, 4 Feb 2014 05:58:11 -0800 To: Juergen Quittek Cc: "draft-ietf-eman-framework@tools.ietf.org" , "eman@ietf.org" Subject: Re: [eman] Mail regarding draft-ietf-eman-framework 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: Tue, 04 Feb 2014 13:58:17 -0000 Juergen, I must respectfully point out that what while you are free (and welcome) to e= xpress your opinion in this WG and on the draft, it is not your place to gau= ge or determine consensus - that up to the chairs. After careful analysis= of the situation, in Nevil's and my opinion, "rough consensus" was achieved= via the IETFs guidelines in these matters, as well as consulting with the A= D on this matter. Thank you, Tom=20 > On Feb 4, 2014, at 12:43 AM, Juergen Quittek wrote: >=20 > Dear Nevil, >=20 > I accept your decision as eman co-chair. >=20 > However,=20 > I challenge your statement that "SHOULD" vs. "MUST" is a typo. > This decision has still been made with NO technical reason for the MUST,=20= > but WITH technical reasons against the MUST. > I do not see clear consensus on this decision in the WG and=20 > request to have this reflected in the write-up for the framework draft.=20= >=20 > Cheers, > Juergen >=20 >=20 >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Nevil Brownlee >> Sent: Montag, 3. Februar 2014 23:14 >> To: draft-ietf-eman-framework@tools.ietf.org >> Cc: eman@ietf.org >> Subject: [eman] Mail regarding draft-ietf-eman-framework >>=20 >>=20 >> Hi Framework authors: >>=20 >> Your WG co-chairs have considered the 11.45th-hour discussion on MUST vs >> SHOULD for energy management domains. >>=20 >> We believe that making this change will - effectively - "fix a typo? in t= he >> framework draft. Please publish a new version, with that change. >>=20 >> Thanks to all who contributed to this discussion. >>=20 >> Cheers, Nevil & Tom >>=20 >> -- >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> _______________________________________________ >> 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 >=20 From jparello@cisco.com Tue Feb 4 08:00:54 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 6F38E1A0155 for ; Tue, 4 Feb 2014 08:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 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.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_QUOTING=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 IdXjOLvTfLpU for ; Tue, 4 Feb 2014 08:00:52 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B669B1A012F for ; Tue, 4 Feb 2014 08:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4044; q=dns/txt; s=iport; t=1391529652; x=1392739252; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7OPbV2IJI79mTdUYd3EM6riXr6mun/QejKfOktv+rM0=; b=WVewGA8K/CMXb/b5CEtYFf287YdCZ5zl6OMovTfMRiSpI6q5iHfbHfeE 1SDeWqm4E7COCJjQp8fD3YBGgqYoIYXh+2NpeH6ZAYKuGFDUSPeCK6Mhr BfjauqSrY5qsVRh7uVNeuxi5258TWCCncTMKgG4FinMBZ+apHWlnRIXSb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAFcO8VKtJV2Z/2dsb2JhbABZgww4vnCBDBZ0giUBAQEDAQEBARodNAsFBwQCAQgRBAEBAR4FBAcnCxQJCAIEDgWHfQgNziQTBI4TCgcBAhsIKwcGgx6BFASUQoNpkiGBb4E+gWgJFw X-IronPort-AV: E=Sophos;i="4.95,780,1384300800"; d="scan'208";a="301780227" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 04 Feb 2014 16:00:52 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s14G0qDV004706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 16:00:52 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.245]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 10:00:51 -0600 From: "John Parello (jparello)" To: Juergen Quittek Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvDuHAOCWuIKk+6AFZjGPomhJqd7ywAgAeBMQD//9mZYg== Date: Tue, 4 Feb 2014 16:00:51 +0000 Message-ID: <06D999B9-C7B4-45C5-8DDF-9DD411B9EC7A@cisco.com> References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> , <9AB93E4127C26F4BA7829DEFDCE5A6E868918F95@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E868918F95@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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: Tue, 04 Feb 2014 16:00:54 -0000 To clarify to the list again JQ you are mistaken and I think this will conf= use readers who only look at the email and not the code in the framework. This can be exactly modeled via the example i sent to the authors and list= . I want to clarify so that anyone reading can get the correct example. """" Domain is an attribute of the super class EnergyObject and available for c= omponents and PowerInterfaces. To use the psuedo code in the framework. =20 DeviceX.domain=3D'foo' DeviceX.powerInterfaces[1].domain=3D'bar' DeviceX.powerInterfaces[2].domain=3D'bin """" This precisely models the case. The device has two power supplies modeled b= y power interfaces as inlets. Each supply is in a different domain.=20 The technical reason for the scalar is that the container object is the vec= tor not the attribute. Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Feb 4, 2014, at 4:18 AM, "Juergen Quittek" wrote: > Hi Brad, >=20 > I am much in line with what you write. >=20 > If a dual-supplied server receives power from two metering domains "suppl= yA" and "supplyB", then we can claim this server to be member of domain "su= pplyA,supplyB". A management system that supports only one domain per devic= e would create a new domain called "supplyA,supplyB" (very similar to what = you suggested, while a management system supporting multiple domains would = model the server as a device with two memberships, one in domain "supplyA" = and one in domain "supplyB". >=20 > Cheers, > Juergen >=20 >> -----Original Message----- >> From: Brad Schoening [mailto:brads@coraid.com] >> Sent: Donnerstag, 30. Januar 2014 18:42 >> To: Juergen Quittek; Thomas Nadeau; eman mailing list >> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring- >> mib-08 and draft-ietf-eman-energy-aware-mib-13 >>=20 >> Juergen, >>=20 >> In your dual power supply example, I would think of these as three >> domains: supplyA, supplyB and supplyAB. The new domain supplyAB is a >> high-reliabliy domain. You don't mention what the power policy of this = new >> combined domain is, but there could be several choices for supplyAB. >>=20 >> Consider a more complicated example, you have a chassis with three power >> supply modules. There are at least three different policies that could = be >> applied: >>=20 >> - Power module redundancy - total power allowed is one less than the >> number of supply modules >> E.g., total power is 2 x. >>=20 >> - Power module redundancy with throttling - total power allowed is equal= to >> available power, but >> requires consumers to throttle down if one module fails. E.g., total p= ower is >> between 2x and 3x. >>=20 >> - Basic power w/o redundancy - total power allowed is equal to all avail= able >> power with no redundancy. E.g., total power is 3x. >>=20 >> Combining power domains likely always invokes a policy and thus in the >> eman model, creates a new domain. >>=20 >> This approach is compatible with the chairs suggestion of MUST. >>=20 >> Regards, >>=20 >>=20 >> Brad >>=20 >> On 1/29/14 3:41 PM, "Juergen Quittek" wrote: >>=20 >>> 1. Having a device limited to a single domain membership is a >>> limitation/feature of Cisco's EnergyWise for which in all the long >>> discussions we had in past year never any technical reason was given >>> (although it was asked for multiple times). In the contrary, I gave use >>> cases where it is REQUIRED to have two or more domains. An obvious >>> example is a highly reliable server that has dual power supply. Its two >>> power supply lines SHOULD be in different domains in order to be better >>> protected from local power supply failures. This server should be given >>> means to report via the MIB that it is member of two domains. >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From karagian@cs.utwente.nl Tue Feb 4 08:33:27 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 DCBB91A0130 for ; Tue, 4 Feb 2014 08:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_QUOTING=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 O20F8g2S9bUM for ; Tue, 4 Feb 2014 08:33:22 -0800 (PST) Received: from out27-ams.mf.surf.net (out27-ams.mf.surf.net [145.0.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9DA1A0207 for ; Tue, 4 Feb 2014 08:33:22 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s14GX6D8019937; Tue, 4 Feb 2014 17:33:15 +0100 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 4 Feb 2014 17:33:16 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.41]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Tue, 4 Feb 2014 17:33:10 +0100 From: To: Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvEgRJuGxPV9EuHqVzSGOSTU5qdedQAgAeBMACAAD4ugIAAGZ9w Date: Tue, 4 Feb 2014 16:33:10 +0000 Message-ID: References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> , <9AB93E4127C26F4BA7829DEFDCE5A6E868918F95@DAPHNIS.office.hd> <06D999B9-C7B4-45C5-8DDF-9DD411B9EC7A@cisco.com> In-Reply-To: <06D999B9-C7B4-45C5-8DDF-9DD411B9EC7A@cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.005 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=15; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uLmgxf3E - b90fe482d4d9 - 20140204 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: eman@ietf.org Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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: Tue, 04 Feb 2014 16:33:28 -0000 Hi John, Thanks for the explanation! Best regards, Georgios > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of John Parello > (jparello) > Sent: dinsdag 4 februari 2014 17:01 > To: Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring- > mib-08 and draft-ietf-eman-energy-aware-mib-13 >=20 > To clarify to the list again JQ you are mistaken and I think this will co= nfuse > readers who only look at the email and not the code in the framework. >=20 > This can be exactly modeled via the example i sent to the authors and li= st. I > want to clarify so that anyone reading can get the correct example. >=20 >=20 > """" > Domain is an attribute of the super class EnergyObject and available for > components and PowerInterfaces. To use the psuedo code in the > framework. >=20 > DeviceX.domain=3D'foo' > DeviceX.powerInterfaces[1].domain=3D'bar' > DeviceX.powerInterfaces[2].domain=3D'bin > """" >=20 > This precisely models the case. The device has two power supplies modeled > by power interfaces as inlets. Each supply is in a different domain. >=20 > The technical reason for the scalar is that the container object is the v= ector > not the attribute. > Jp >=20 > Sent from my iPad > (expect ridiculous spelling mistakes) >=20 > On Feb 4, 2014, at 4:18 AM, "Juergen Quittek" wrote: >=20 > > Hi Brad, > > > > I am much in line with what you write. > > > > If a dual-supplied server receives power from two metering domains > "supplyA" and "supplyB", then we can claim this server to be member of > domain "supplyA,supplyB". A management system that supports only one > domain per device would create a new domain called "supplyA,supplyB" > (very similar to what you suggested, while a management system supporting > multiple domains would model the server as a device with two > memberships, one in domain "supplyA" and one in domain "supplyB". > > > > Cheers, > > Juergen > > > >> -----Original Message----- > >> From: Brad Schoening [mailto:brads@coraid.com] > >> Sent: Donnerstag, 30. Januar 2014 18:42 > >> To: Juergen Quittek; Thomas Nadeau; eman mailing list > >> Subject: Re: [eman] WG Last Call for > >> draft-ietf-eman-energy-monitoring- > >> mib-08 and draft-ietf-eman-energy-aware-mib-13 > >> > >> Juergen, > >> > >> In your dual power supply example, I would think of these as three > >> domains: supplyA, supplyB and supplyAB. The new domain supplyAB is a > >> high-reliabliy domain. You don't mention what the power policy of > >> this new combined domain is, but there could be several choices for > supplyAB. > >> > >> Consider a more complicated example, you have a chassis with three > >> power supply modules. There are at least three different policies > >> that could be > >> applied: > >> > >> - Power module redundancy - total power allowed is one less than the > >> number of supply modules E.g., total power is 2 x. > >> > >> - Power module redundancy with throttling - total power allowed is > >> equal to available power, but requires consumers to throttle down if > >> one module fails. E.g., total power is between 2x and 3x. > >> > >> - Basic power w/o redundancy - total power allowed is equal to all > >> available power with no redundancy. E.g., total power is 3x. > >> > >> Combining power domains likely always invokes a policy and thus in > >> the eman model, creates a new domain. > >> > >> This approach is compatible with the chairs suggestion of MUST. > >> > >> Regards, > >> > >> > >> Brad > >> > >> On 1/29/14 3:41 PM, "Juergen Quittek" wrote: > >> > >>> 1. Having a device limited to a single domain membership is a > >>> limitation/feature of Cisco's EnergyWise for which in all the long > >>> discussions we had in past year never any technical reason was given > >>> (although it was asked for multiple times). In the contrary, I gave > >>> use cases where it is REQUIRED to have two or more domains. An > >>> obvious example is a highly reliable server that has dual power > >>> supply. Its two power supply lines SHOULD be in different domains in > >>> order to be better protected from local power supply failures. This > >>> server should be given means to report via the MIB that it is member = of > two domains. > > > > _______________________________________________ > > 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 Quittek@neclab.eu Tue Feb 4 10:34: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 416BA1A0127 for ; Tue, 4 Feb 2014 10:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, 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 2ChweImY5tAn for ; Tue, 4 Feb 2014 10:34:45 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 295421A0125 for ; Tue, 4 Feb 2014 10:34:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1B36A106B4D; Tue, 4 Feb 2014 19:34:44 +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 lXyMM62fAupr; Tue, 4 Feb 2014 19:34:43 +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 E1620106B4E; Tue, 4 Feb 2014 19:34:23 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 4 Feb 2014 19:34:02 +0100 From: Juergen Quittek To: "Thomas D. Nadeau" Thread-Topic: [eman] Mail regarding draft-ietf-eman-framework Thread-Index: Ac8h16Ee9AZjzNJeT7ir2FCl+2IVOw== Date: Tue, 4 Feb 2014 18:34:02 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E8689195B3@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-eman-framework@tools.ietf.org" , "eman@ietf.org" Subject: Re: [eman] Mail regarding draft-ietf-eman-framework 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: Tue, 04 Feb 2014 18:34:49 -0000 Hi Tom, I'm Sorry if it sounded like telling you how to do your job.=20 And I did not challenge that it was a "rough" consensus.=20 Best regards, Juergen > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Dienstag, 4. Februar 2014 14:58 > To: Juergen Quittek > Cc: Nevil Brownlee; draft-ietf-eman-framework@tools.ietf.org; > eman@ietf.org > Subject: Re: [eman] Mail regarding draft-ietf-eman-framework >=20 > Juergen, >=20 > I must respectfully point out that what while you are free (and welcome) = to > express your opinion in this WG and on the draft, it is not your place to= gauge > or determine consensus - that up to the chairs. After careful analysis= of the > situation, in Nevil's and my opinion, "rough consensus" was achieved via = the > IETFs guidelines in these matters, as well as consulting with the AD on t= his > matter. >=20 > Thank you, >=20 > Tom >=20 >=20 > > On Feb 4, 2014, at 12:43 AM, Juergen Quittek wrote: > > > > Dear Nevil, > > > > I accept your decision as eman co-chair. > > > > However, > > I challenge your statement that "SHOULD" vs. "MUST" is a typo. > > This decision has still been made with NO technical reason for the > > MUST, but WITH technical reasons against the MUST. > > I do not see clear consensus on this decision in the WG and request to > > have this reflected in the write-up for the framework draft. > > > > Cheers, > > Juergen > > > > > >> -----Original Message----- > >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Nevil > Brownlee > >> Sent: Montag, 3. Februar 2014 23:14 > >> To: draft-ietf-eman-framework@tools.ietf.org > >> Cc: eman@ietf.org > >> Subject: [eman] Mail regarding draft-ietf-eman-framework > >> > >> > >> Hi Framework authors: > >> > >> Your WG co-chairs have considered the 11.45th-hour discussion on MUST > >> vs SHOULD for energy management domains. > >> > >> We believe that making this change will - effectively - "fix a typo? > >> in the framework draft. Please publish a new version, with that chang= e. > >> > >> Thanks to all who contributed to this discussion. > >> > >> Cheers, Nevil & Tom > >> > >> -- > >> --------------------------------------------------------------------- > >> Nevil Brownlee Computer Science Department > >> Phone: +64 9 373 7599 x88941 The University of Auckland > >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > >> _______________________________________________ > >> 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 joelja@bogus.com Tue Feb 4 10:58:09 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 CAE7B1A0165 for ; Tue, 4 Feb 2014 10:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 qmXxz-wo14tD for ; Tue, 4 Feb 2014 10:58:07 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id ACB4B1A0164 for ; Tue, 4 Feb 2014 10:58:07 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s14Iw6Bs012542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Feb 2014 18:58:06 GMT (envelope-from joelja@bogus.com) Message-ID: <52F13838.4040609@bogus.com> Date: Tue, 04 Feb 2014 10:58:00 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Juergen Quittek , "Thomas D. Nadeau" References: <9AB93E4127C26F4BA7829DEFDCE5A6E8689195B3@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8689195B3@DAPHNIS.office.hd> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k2H8SPLRCiUobBwLEfmxLMTikq8Cko7oU" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 04 Feb 2014 18:58:07 +0000 (UTC) Cc: "eman@ietf.org" , "draft-ietf-eman-framework@tools.ietf.org" Subject: Re: [eman] Mail regarding draft-ietf-eman-framework 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: Tue, 04 Feb 2014 18:58:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k2H8SPLRCiUobBwLEfmxLMTikq8Cko7oU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At some point if we can live with the result we draw a line under it and move on. I think we've arrived. thanks to the chairs for threading the needle. joel On 2/4/14, 10:34 AM, Juergen Quittek wrote: > Hi Tom, > I'm Sorry if it sounded like telling you how to do your job.=20 > And I did not challenge that it was a "rough" consensus.=20 > Best regards, > Juergen >=20 >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Dienstag, 4. Februar 2014 14:58 >> To: Juergen Quittek >> Cc: Nevil Brownlee; draft-ietf-eman-framework@tools.ietf.org; >> eman@ietf.org >> Subject: Re: [eman] Mail regarding draft-ietf-eman-framework >> >> Juergen, >> >> I must respectfully point out that what while you are free (and welcom= e) to >> express your opinion in this WG and on the draft, it is not your place= to gauge >> or determine consensus - that up to the chairs. After careful analy= sis of the >> situation, in Nevil's and my opinion, "rough consensus" was achieved v= ia the >> IETFs guidelines in these matters, as well as consulting with the AD o= n this >> matter. >> >> Thank you, >> >> Tom >> >> >>> On Feb 4, 2014, at 12:43 AM, Juergen Quittek wrot= e: >>> >>> Dear Nevil, >>> >>> I accept your decision as eman co-chair. >>> >>> However, >>> I challenge your statement that "SHOULD" vs. "MUST" is a typo. >>> This decision has still been made with NO technical reason for the >>> MUST, but WITH technical reasons against the MUST. >>> I do not see clear consensus on this decision in the WG and request t= o >>> have this reflected in the write-up for the framework draft. >>> >>> Cheers, >>> Juergen >>> >>> >>>> -----Original Message----- >>>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Nevil >> Brownlee >>>> Sent: Montag, 3. Februar 2014 23:14 >>>> To: draft-ietf-eman-framework@tools.ietf.org >>>> Cc: eman@ietf.org >>>> Subject: [eman] Mail regarding draft-ietf-eman-framework >>>> >>>> >>>> Hi Framework authors: >>>> >>>> Your WG co-chairs have considered the 11.45th-hour discussion on MUS= T >>>> vs SHOULD for energy management domains. >>>> >>>> We believe that making this change will - effectively - "fix a typo?= >>>> in the framework draft. Please publish a new version, with that cha= nge. >>>> >>>> Thanks to all who contributed to this discussion. >>>> >>>> Cheers, Nevil & Tom >>>> >>>> -- >>>> --------------------------------------------------------------------= - >>>> Nevil Brownlee Computer Science Department= >>>> Phone: +64 9 373 7599 x88941 The University of Auckland= >>>> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand= >>>> _______________________________________________ >>>> 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 >>> > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 --k2H8SPLRCiUobBwLEfmxLMTikq8Cko7oU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLxODkACgkQ8AA1q7Z/VrJdxwCfSeYrupxCduX1fmV/6QgaEiEZ /ZsAn0ifpTcbkm8I9D1b3EqH/9EdGMpg =qZzn -----END PGP SIGNATURE----- --k2H8SPLRCiUobBwLEfmxLMTikq8Cko7oU-- From tnadeau@lucidvision.com Tue Feb 4 11:19:45 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 65BD11A0127 for ; Tue, 4 Feb 2014 11:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 4f_Dm0OtD-5I for ; Tue, 4 Feb 2014 11:19:40 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 302F41A01F4 for ; Tue, 4 Feb 2014 11:19:38 -0800 (PST) Received: from [10.36.0.205] (sccc-66-78-236-243.smartcity.com [66.78.236.243]) by lucidvision.com (Postfix) with ESMTP id D0E6826DC4EB; Tue, 4 Feb 2014 14:19:36 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_115E3443-6A3A-41F8-8827-D951EF9BA7E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8689195B3@DAPHNIS.office.hd> Date: Tue, 4 Feb 2014 11:19:35 -0800 Message-Id: <00D63273-70DA-410A-B314-6ADE682D2F64@lucidvision.com> References: <9AB93E4127C26F4BA7829DEFDCE5A6E8689195B3@DAPHNIS.office.hd> To: Juergen Quittek X-Mailer: Apple Mail (2.1827) Cc: "draft-ietf-eman-framework@tools.ietf.org" , "eman@ietf.org" Subject: Re: [eman] Mail regarding draft-ietf-eman-framework 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: Tue, 04 Feb 2014 19:19:45 -0000 --Apple-Mail=_115E3443-6A3A-41F8-8827-D951EF9BA7E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No worries. 8) --Tom On Feb 4, 2014:10:34 AM, at 10:34 AM, Juergen Quittek = wrote: > Hi Tom, > I'm Sorry if it sounded like telling you how to do your job.=20 > And I did not challenge that it was a "rough" consensus.=20 > Best regards, > Juergen >=20 >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Dienstag, 4. Februar 2014 14:58 >> To: Juergen Quittek >> Cc: Nevil Brownlee; draft-ietf-eman-framework@tools.ietf.org; >> eman@ietf.org >> Subject: Re: [eman] Mail regarding draft-ietf-eman-framework >>=20 >> Juergen, >>=20 >> I must respectfully point out that what while you are free (and = welcome) to >> express your opinion in this WG and on the draft, it is not your = place to gauge >> or determine consensus - that up to the chairs. After careful = analysis of the >> situation, in Nevil's and my opinion, "rough consensus" was achieved = via the >> IETFs guidelines in these matters, as well as consulting with the AD = on this >> matter. >>=20 >> Thank you, >>=20 >> Tom >>=20 >>=20 >>> On Feb 4, 2014, at 12:43 AM, Juergen Quittek = wrote: >>>=20 >>> Dear Nevil, >>>=20 >>> I accept your decision as eman co-chair. >>>=20 >>> However, >>> I challenge your statement that "SHOULD" vs. "MUST" is a typo. >>> This decision has still been made with NO technical reason for the >>> MUST, but WITH technical reasons against the MUST. >>> I do not see clear consensus on this decision in the WG and request = to >>> have this reflected in the write-up for the framework draft. >>>=20 >>> Cheers, >>> Juergen >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Nevil >> Brownlee >>>> Sent: Montag, 3. Februar 2014 23:14 >>>> To: draft-ietf-eman-framework@tools.ietf.org >>>> Cc: eman@ietf.org >>>> Subject: [eman] Mail regarding draft-ietf-eman-framework >>>>=20 >>>>=20 >>>> Hi Framework authors: >>>>=20 >>>> Your WG co-chairs have considered the 11.45th-hour discussion on = MUST >>>> vs SHOULD for energy management domains. >>>>=20 >>>> We believe that making this change will - effectively - "fix a = typo? >>>> in the framework draft. Please publish a new version, with that = change. >>>>=20 >>>> Thanks to all who contributed to this discussion. >>>>=20 >>>> Cheers, Nevil & Tom >>>>=20 >>>> -- >>>> = --------------------------------------------------------------------- >>>> Nevil Brownlee Computer Science Department >>>> Phone: +64 9 373 7599 x88941 The University of Auckland >>>> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >>>> _______________________________________________ >>>> 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 >>>=20 >=20 --Apple-Mail=_115E3443-6A3A-41F8-8827-D951EF9BA7E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS8T1HAAoJEPcO+I7eiUJZJAMQAKLNjNbsOOk5WqgtHgCVbd2Y hqvwVbhOmsThMVq66CcyWCDeW7tELWUbRkRhhSCUoEU7tC+Jy+kljw5pCPOo4Ha9 qxjyw02RLjMqv0biOMZ4mxtRe37HUEyb0W0rA4snyuHMBXTjfj6gXxfSWxIVFGA9 CvZq5hSvbYkZ87dRU0379iD+U3wvR3IIEO7ydTPj3WEeZo4G6XrkNCqDL9KpqLkw 9coyxRc2UTaaratmC1s9YlbnJqYoFkeCfx9+4p/SsCZ9xGMgRHi7/GxcJr3WA6HL W9uZmSy8qffJjWRIeZY5lEHoFhIvd3uMxMKTN2xnb1++Zfz7eOKF7Qxt2i/EWgjd qVvVW8/pfu9BKxaLaaSfqe40b6GjtNB6CJUWKj/4N0Gg66AXEpK5/I4+3dIQ/zFb 8GUxtIz6AeJBIOWaI1wbdr2bONhZ7quKaeTK2cc/OhJZTaE+RGx8DHm8EWjGx6F4 dR1ee98in5STh5rkyX2Q+HiFVkXX5RdrYkrC0jDCC91qyehsY5UeVOTYDz5C6DpY XAgT+5qtO74nT0ULbuBGgQb5oV5vd4hNBLzX+AtCgy1sVFyBDMS6oOMlDF5sC3IH l8UmWlbfntIfd2Yv6O3SfteUZPYowJ2jGhmBcNv2T4uHytrYb2xpJSOeK/iPtT9o z2Z6ayyf/uKYnuAessMI =KzI6 -----END PGP SIGNATURE----- --Apple-Mail=_115E3443-6A3A-41F8-8827-D951EF9BA7E9-- From tnadeau@lucidvision.com Tue Feb 4 11:23:06 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 2745D1A01EF for ; Tue, 4 Feb 2014 11:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 OIZ_tUMYmsUk for ; Tue, 4 Feb 2014 11:22:58 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 955561A01F1 for ; Tue, 4 Feb 2014 11:22:58 -0800 (PST) Received: from [10.36.0.205] (sccc-66-78-236-243.smartcity.com [66.78.236.243]) by lucidvision.com (Postfix) with ESMTP id B228C26DC52A for ; Tue, 4 Feb 2014 14:22:57 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_55A36934-56EF-44C8-B0AD-40D872BD7099"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <543DEA53-695F-4B49-93B1-AB0425281740@lucidvision.com> Date: Tue, 4 Feb 2014 11:22:55 -0800 To: eman mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [eman] Change of Affilliation 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: Tue, 04 Feb 2014 19:23:06 -0000 --Apple-Mail=_55A36934-56EF-44C8-B0AD-40D872BD7099 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear EMAN Participants - As of Monday, I am now affiliated with (employed by) Brocade = Communications. I am no longer affiliated with Juniper Networks. As = always, I can be reached at tnadeau@lucidvision.com for EMAN business. = If you wish to communicate with me at Brocade, feel free to email = tnadeau@brocade.com. --Tom --Apple-Mail=_55A36934-56EF-44C8-B0AD-40D872BD7099 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS8T4PAAoJEPcO+I7eiUJZhWYP/3Y8A42/rdslU/ChnMkl9gX4 zalYL2nI2OfBjpzUZE+M8XIf0b97p8i/Osw6Kbs6dA0UmxILZNjGGUaRNo8qrZR3 H78+ON9fen56+3J9W0h8F6BltvPOhcNyKTJEZSHJFXnfidpylHh0ErntVKwOvcPd DXZbhpdUsJyAS78VsVjDMSzGfyqexCG/20Cx925GI5SEkh2l5IHM+ujAYmOgZm9k U3OcqWHZbL6jcJPHxUdNKUau5v+4yAOthhz9UVJDDGV+lqSlBQqJI6fygP/w/D1S oehDtPGxWYa6bLCr4PIMj9J1lD27hSg56sFHx+8XG8TIUirHPQzo9BX53vQo1opH QutHeXkXFwjgL/6BXQgYuwQl94qwsSEP1ja0TTLdgLViQ6pxkxFOhyraxlqFd/n1 O/Bo2axmr/bGcXjEDKf4fhqfxYiBCrCnKZTzYgoQf3pEYWM3SkWI9b9NI2nh9vfv tFAmfxs0aDpU+uEQUwSKGDNjWlxrmjmPyHb3hlIy2TNmIFgYKt4S3KwPN2F6rnVE tEsmbAbRjh1dn+ctBUrvJDn64aIPvY/1OUS6nJnkoM6ysoTNTdN8nNHuE52xo/sq qo6X82aXiP+XNZZ87ip7HTIX7CMlUcQTSRRhithvBtPERTQlKTTEy44RFnPegKvg 3EIALwBDVSuMvuSANOQj =G6Jk -----END PGP SIGNATURE----- --Apple-Mail=_55A36934-56EF-44C8-B0AD-40D872BD7099-- From tnadeau@lucidvision.com Sat Feb 8 18:20:07 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 E80831A066E for ; Sat, 8 Feb 2014 18:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.548] 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 NQa2s5ExJ3aI for ; Sat, 8 Feb 2014 18:20:05 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id BAB5B1A0636 for ; Sat, 8 Feb 2014 18:20:04 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 96B8526E3F92 for ; Sat, 8 Feb 2014 21:20:04 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_004DAF99-127B-4BF5-817B-FEB8ADB8A5AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Date: Sat, 8 Feb 2014 21:20:03 -0500 To: eman mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [eman] IETF Draft Submission Deadline 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: Sun, 09 Feb 2014 02:20:07 -0000 --Apple-Mail=_004DAF99-127B-4BF5-817B-FEB8ADB8A5AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI the draft submission deadline for this IETF falls on a = Friday instead of Monday.=20 > 2014-02-14 (Friday): Internet Draft submission cut-off (for all > drafts, including -00) by UTC 23:59, upload using IETF ID > Submission Tool. --Apple-Mail=_004DAF99-127B-4BF5-817B-FEB8ADB8A5AD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS9uXTAAoJEPcO+I7eiUJZ6voQAIIoJo+Z4c2uPAwAQ0gfCoLg 4tKYDK8nOtIvHdcGNHlFFC5QvXZzm0jVeatPloD5u/gNV2J2VxAHCmzxwdepOMdL c1cBP3GG5pBbeIi77GlNsLR549+f/0Nf5RM0ElJEeJvJJYKSGGIfWe35qlBXRrxi FHDnPaORDj5wrnoPc8yItlzZmoxOIruOw+LyH3AWg7r/p4OxH40hFBkg2ACGOSBP NJBCv/YDxxw18EF7IHWwfBrU2IKF78ADLAc6lo8N46eZjJJ2IcuOlm80lOIx9yGC AXOf86eQfJt43MS29UMXf3ihs4bTX+3EzdOptnCDqgoWbRfZGusUOdmKjZvQI1r9 4aIFzx89u9umfWViOmtU4giI3+OqPxdnMJTmckaCCGsRkUWaNQXDvJGkeQhwrrLy xSrQgfbUm/Dvye5Ssaka4/d2rUVZFzFRJ9ppziXHh0UcH/K6D/XOh0fc2HvqkU/O Cw53+MIuuy55TSpfiw+AWi2bRrIsnGGKCYhsWCp32Ie5igtjiR8ibq2yBYciPdM8 aUGXsa+996Hdtt/ug9WIsk0LXEDqOcSjv9us4p8PldC65qiuP7xo+bNNvU3gG6kf qOiL32EB9N6LBYxQocVYHwv9RnzVgplNR2BdQzyTdvT2QKIhaOlVOXVKYqBaAZE6 9s/LQ7S3ce182z2VYnii =jB9+ -----END PGP SIGNATURE----- --Apple-Mail=_004DAF99-127B-4BF5-817B-FEB8ADB8A5AD-- From iesg-secretary@ietf.org Mon Feb 10 06:23:26 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 B055F1A086E; Mon, 10 Feb 2014 06:23:26 -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 P70t_jyPkpL2; Mon, 10 Feb 2014 06:23:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 249CF1A02FA; Mon, 10 Feb 2014 06:23:24 -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.0.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140210142323.2903.54963.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 06:23:23 -0800 Cc: eman@ietf.org Subject: [eman] Last Call: (Energy Management Framework) 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, 10 Feb 2014 14:23:28 -0000 The IESG has received a request from the Energy Management WG (eman) to consider the following document: - 'Energy Management Framework' 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-02-24. 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 This document defines a framework for Energy Management for devices and device components within or connected to communication networks. The framework presents a physical reference model and information model. The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally the framework models relationships and capabilities between Energy Objects. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eman-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eman-framework/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2161/ From internet-drafts@ietf.org Mon Feb 10 09:54:17 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 8C6491A01E8; Mon, 10 Feb 2014 09:54:17 -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 IG83sRyF6X3m; Mon, 10 Feb 2014 09:54:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BA21A07AD; Mon, 10 Feb 2014 09:54:15 -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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210175415.8234.22973.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 09:54:15 -0800 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-14.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: Mon, 10 Feb 2014 17:54:17 -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-14.txt Pages : 34 Date : 2014-02-10 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-energy-aware-mib-14 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 moulchan@cisco.com Mon Feb 10 10:00:19 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 77DD51A0386; Mon, 10 Feb 2014 10:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 X7jSehTLnlGm; Mon, 10 Feb 2014 10:00:17 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id F1CDE1A0326; Mon, 10 Feb 2014 10:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6124; q=dns/txt; s=iport; t=1392055217; x=1393264817; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=92r10nQywdCKKi33Q6XSUGPaurZkS/CUCnPP+l/2Vic=; b=LUX3RiwJYzNfZIY2x6DI6OpBMXxCZnTrjNBu3LzE0Y3T+0JSd1f+K05Z 2FZCxkYua8hw28p4ZT9j+9RCDCHwvsO7RH2aFdvlLeIGwxvwuKL2vzUuR 1AZn/41LVCoovufDzi4yTkB5gEs5/GWZxxAac07x3z/7y3voIXJj/H2ff w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncGAFwT+VKtJXG//2dsb2JhbABZgkhEOFEGhB+ybohUgRMWdIImAQEEAQEBawQHEAIBCD8HJwsUEQIEAQ0FCYd8CAXJFBeOeQQHCYQvBJgrgTKQboMtgio X-IronPort-AV: E=Sophos;i="4.95,819,1384300800"; d="scan'208,217";a="19314148" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-2.cisco.com with ESMTP; 10 Feb 2014 18:00:00 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1AI00Vd006204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 18:00:00 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.26]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 12:00:00 -0600 From: "Mouli Chandramouli (moulchan)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-14.txt Thread-Index: AQHPJokmQg6fnLtjpkmR6HJyYCQx25qvh4eA Date: Mon, 10 Feb 2014 17:59:59 +0000 Message-ID: References: <20140210175415.8234.22973.idtracker@ietfa.amsl.com> In-Reply-To: <20140210175415.8234.22973.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.3.9.131030 x-originating-ip: [10.65.50.195] Content-Type: multipart/alternative; boundary="_000_CF1F10511E44Cmoulchanciscocom_" MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-14.txt 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: Mon, 10 Feb 2014 18:00:19 -0000 --_000_CF1F10511E44Cmoulchanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Thanks for all the comments from many reviewers (Alan Luchuk, Juergen Quitt= ek, Georgios, and Tom) from LC for the draft. Regards Moil A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IET= F. Title : Energy Object Context MIB Authors : John Parello Benoit Claise Mouli Chandramouli Filename : draft-ietf-eman-energy-aware-mib-14.txt Pages : 34 Date : 2014-02-10 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-aware-mib-14 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --_000_CF1F10511E44Cmoulchanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello all,

Thanks for all the comments from many reviewers (Alan Luchuk, Juergen = Quittek,  Georgios,  and Tom) from LC for the draft.

Regards
Moil



A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Energy Management Working Group of th= e IETF.

        Title   = ;        : Energy Object Context MIB
        Authors  &nb= sp;      : John Parello
           &nbs= p;            &= nbsp; Benoit Claise
           &nbs= p;            &= nbsp; Mouli Chandramouli
Filena= me        : draft-ietf-eman-energy-= aware-mib-14.txt
Pages&= nbsp;          : 34
Date&n= bsp;           : 201= 4-02-10

Abstract:
        This document defines = a subset of a Management Information Base
        (MIB) for energy manag= ement of devices. The module addresses
        device identification,= context information, and the energy
        relationships between = devices.

    

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-14

A diff from the previous version is available at:


Please note that it may take a couple of minutes from the time of subm= ission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

_______________________________________________
eman mailing list

--_000_CF1F10511E44Cmoulchanciscocom_-- From tnadeau@lucidvision.com Tue Feb 11 08:02:40 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 36A5C1A0548 for ; Tue, 11 Feb 2014 08:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 lIVPBIeVKMg1 for ; Tue, 11 Feb 2014 08:02:34 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 81C051A0591 for ; Tue, 11 Feb 2014 08:02:34 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id B5DB026E9E42 for ; Tue, 11 Feb 2014 11:02:33 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_139A72CC-3B70-48FE-A21C-5E06B340D46E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> Date: Tue, 11 Feb 2014 11:02:32 -0500 To: eman mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [eman] Read-Only or Read-Write EMAN MIBs 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: Tue, 11 Feb 2014 16:02:40 -0000 --Apple-Mail=_139A72CC-3B70-48FE-A21C-5E06B340D46E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 EMAN WG: The EMAN WG currently has three MIBs that are WG drafts: draft-ietf-eman-battery-mib-11=09 draft-ietf-eman-energy-aware-mib-14 draft-ietf-eman-energy-monitoring-mib-08 At present Benoit as AD, the Ops Directorate and MIB Doctors are = preparing a statement to WGs that strongly recommends against MIBs with = writable objects unless the working group has a strong consensus to do = so. The current *draft* of the statement is listed here for your = information: The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state=20 should only be produced by working groups in cases of clear utility and=20= overwhelming consensus to use SNMP write operations for configuration. In an effort to head off any potential snafus during the IESG = review of the three EMAN MIBs, I want to poll the WG for consensus on whether = or not=20 to make the current list of WG documents read-write or read-only. If = there is=20 not strong consensus to leave them read-write, Nevil and I will instruct = the=20 editors to edit the documents to remove writable objects. Please post comments on this matter by Friday, February 14, 2014=20= at 9AM EDT. Tom EMAN WG Co-Chair --Apple-Mail=_139A72CC-3B70-48FE-A21C-5E06B340D46E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS+kmZAAoJEPcO+I7eiUJZxg4P/iiXm6pvV0RaEA0zoL+dZhEd oF51UhBqhCJag4ObA+pADmmR8VCghIjFlkKQOoEFSC7Jqh8rTJTgiUKTuJtihWzB m//XBy3ashkK6Hd5MX3BmXbelaDZgXSzqWsZ9hgaGxdMqCRo+obADHwWrDQSbB/r QRmYvQk6EN159a/tCHRBw5SeWjLP4Qlz7/OITKUFn1SdRmahKzA95DumFwy/CtWZ Lf8rmxOiqB83NFi0pbSV/bsVV4YpxJJAAb3u9iABGkGigQbaQDyCigQgRY6hdhHr xSgkP84igjqon6siGV9ygxSjLvWCpsp3Ku43z2zsnet1QfZ3v16JBwyf04XGUCpr 0kS+zUvydd7tbCX93YaCF/yHSJwmCLU5DvCWzzNQsEpyRJvSciN7wpbZDs26Ra2Q TkDNZoZFe3w8fHtW3qjJBDiojahKBs2Ut4X4f/RmDC/CB1Tl3KHfSl+pDC1312Ch UfwI4JV/Ce9NVKpU4KQ2zqnc/wgwEhcgVrQsCo01dre0qNiNaeN6Fi4auVVwJ7IH Tdd3iNv/kjWKKl549rHTEIN1aHREz92+QI3rXeDQ7OMKzr+t6klcXTWY0XThMCjy 66cuHUMQGNx1piCmF0quYwmiX2rhtu1n3SJ17zBk+jiyqCJIZ8rkbRdaLAglsxlj EV4xXn5uqriuC5SD8gAw =6QLw -----END PGP SIGNATURE----- --Apple-Mail=_139A72CC-3B70-48FE-A21C-5E06B340D46E-- From dromasca@avaya.com Wed Feb 12 01:35:51 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 02AEE1A08D8 for ; Wed, 12 Feb 2014 01:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 pO-dUsosyrKb for ; Wed, 12 Feb 2014 01:35:47 -0800 (PST) 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 6DBAD1A08E9 for ; Wed, 12 Feb 2014 01:35:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAARA+1KHCzI1/2dsb2JhbABagmshgQ+/JYEQFnSCJQEBAQEDEig0FwQCAQgNAQMEAQELFAkHMhQJCAIEARIIGodjAZw8rG0XjhE3OAaDHoEUBJ8ZizKDLYIq X-IronPort-AV: E=Sophos;i="4.95,831,1384318800"; d="scan'208";a="42662934" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Feb 2014 04:35:45 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 12 Feb 2014 04:22:52 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 10:35:42 +0100 From: "Romascanu, Dan (Dan)" To: Thomas Nadeau , eman mailing list Thread-Topic: [eman] Read-Only or Read-Write EMAN MIBs Thread-Index: AQHPJ0LKAi3Xzvo/0kC6ip3cJ++yrZqxWCcg Date: Wed, 12 Feb 2014 09:35:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3FE569@AZ-FFEXMB04.global.avaya.com> References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> In-Reply-To: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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, 12 Feb 2014 09:35:51 -0000 Hi, I believe that we need to look carefully what removing writeable objects me= ans at this phase. =20 Let us take a look at the writeable objects in draft-ietf-eman-battery-mib-= 11. There are seven objects with a MAX-ACCESS clause of read-write.=20 One of them is batteryChargingAdminState and this is probably the only 'con= figuration' object. It does not make too much sense to make it read-only, = as there is a corresponding batteryChargingOperState object. Basically mak= ing the MIB module read-only means giving up this functionality and taking = out the object.=20 The other six objects batteryAlarmLowCharge, batteryAlarmLowVoltage, batter= yAlarmLowCapacity, batteryAlarmHighCycleCount, batteryAlarmHighTemperature,= batteryAlarmLowTemperature set thresholds for notifications. Making the MI= B module read-only means that thresholds cannot be set, so there is no use = for the objects, and no use for the respective notifications.=20 What is the plan? Will the WG renounce to these functions? Is the remaining= MIB module consistent enough to be worth making it a standard? If the func= tionality is still desired do we plan to create a YANG module instead? Will= battery devices support NETCONF and YANG?=20 Regards, Dan =20 > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Tuesday, February 11, 2014 6:03 PM > To: eman mailing list > Subject: [eman] Read-Only or Read-Write EMAN MIBs >=20 >=20 > EMAN WG: >=20 > The EMAN WG currently has three MIBs that are WG drafts: >=20 > draft-ietf-eman-battery-mib-11 > draft-ietf-eman-energy-aware-mib-14 > draft-ietf-eman-energy-monitoring-mib-08 >=20 > At present Benoit as AD, the Ops Directorate and MIB Doctors are > preparing a statement to WGs that strongly recommends against MIBs with > writable objects unless the working group has a strong consensus to do so= . > The current *draft* of the statement is listed here for your information: >=20 > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to use the > NETCONF/YANG standards for configuration, specifically in new charters. > SNMP MIB modules modifying persistent configuration state should only be > produced by working groups in cases of clear utility and overwhelming > consensus to use SNMP write operations for configuration. >=20 > In an effort to head off any potential snafus during the IESG review > of the three EMAN MIBs, I want to poll the WG for consensus on whether or > not to make the current list of WG documents read-write or read-only. If > there is not strong consensus to leave them read-write, Nevil and I will > instruct the editors to edit the documents to remove writable objects. >=20 > Please post comments on this matter by Friday, February 14, 2014 at > 9AM EDT. >=20 >=20 > Tom > EMAN WG Co-Chair >=20 >=20 From j.schoenwaelder@jacobs-university.de Wed Feb 12 02:18:01 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 C945D1A091C for ; Wed, 12 Feb 2014 02:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 etFSnn8lI27X for ; Wed, 12 Feb 2014 02:17:58 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0D99B1A091E for ; Wed, 12 Feb 2014 02:17:56 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E05B5214DB; Wed, 12 Feb 2014 11:17:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id szWTAi8d17OL; Wed, 12 Feb 2014 11:17:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36181212A8; Wed, 12 Feb 2014 11:17:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 332032B44D1C; Wed, 12 Feb 2014 11:17:51 +0100 (CET) Date: Wed, 12 Feb 2014 11:17:51 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20140212101751.GA80586@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Thomas Nadeau , eman mailing list References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA2E3FE569@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E3FE569@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 10:18:02 -0000 Hi, if you keep the objects (and I think you should - new guidelines should IMHO not impact almost complete work), I would appreciate if the document is explicit what the persistency properties of these objects are. A MIB doctor might ask that question anyway. /js On Wed, Feb 12, 2014 at 09:35:42AM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > I believe that we need to look carefully what removing writeable objects means at this phase. > > Let us take a look at the writeable objects in draft-ietf-eman-battery-mib-11. There are seven objects with a MAX-ACCESS clause of read-write. > > One of them is batteryChargingAdminState and this is probably the only 'configuration' object. It does not make too much sense to make it read-only, as there is a corresponding batteryChargingOperState object. Basically making the MIB module read-only means giving up this functionality and taking out the object. > > The other six objects batteryAlarmLowCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighCycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature set thresholds for notifications. Making the MIB module read-only means that thresholds cannot be set, so there is no use for the objects, and no use for the respective notifications. > > What is the plan? Will the WG renounce to these functions? Is the remaining MIB module consistent enough to be worth making it a standard? If the functionality is still desired do we plan to create a YANG module instead? Will battery devices support NETCONF and YANG? > > Regards, > > Dan > > > > > > -----Original Message----- > > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > > Sent: Tuesday, February 11, 2014 6:03 PM > > To: eman mailing list > > Subject: [eman] Read-Only or Read-Write EMAN MIBs > > > > > > EMAN WG: > > > > The EMAN WG currently has three MIBs that are WG drafts: > > > > draft-ietf-eman-battery-mib-11 > > draft-ietf-eman-energy-aware-mib-14 > > draft-ietf-eman-energy-monitoring-mib-08 > > > > At present Benoit as AD, the Ops Directorate and MIB Doctors are > > preparing a statement to WGs that strongly recommends against MIBs with > > writable objects unless the working group has a strong consensus to do so. > > The current *draft* of the statement is listed here for your information: > > > > The OPS area recommends the use of NETCONF/YANG standards for > > configuration. IETF working groups are therefore encouraged to use the > > NETCONF/YANG standards for configuration, specifically in new charters. > > SNMP MIB modules modifying persistent configuration state should only be > > produced by working groups in cases of clear utility and overwhelming > > consensus to use SNMP write operations for configuration. > > > > In an effort to head off any potential snafus during the IESG review > > of the three EMAN MIBs, I want to poll the WG for consensus on whether or > > not to make the current list of WG documents read-write or read-only. If > > there is not strong consensus to leave them read-write, Nevil and I will > > instruct the editors to edit the documents to remove writable objects. > > > > Please post comments on this matter by Friday, February 14, 2014 at > > 9AM EDT. > > > > > > Tom > > EMAN WG Co-Chair > > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman -- 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 Feb 12 05:53:31 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 7FFCD1A02C6 for ; Wed, 12 Feb 2014 05:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 wpfalRbuXiAP for ; Wed, 12 Feb 2014 05:53:29 -0800 (PST) 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 1DA6A1A0238 for ; Wed, 12 Feb 2014 05:53:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFACF8+1LGmAcV/2dsb2JhbABagmshgQ+/KIESFnSCJQEBAQEDEig0FwQCAQgNAQMEAQELFAkHMhQJCAIEARIIGodjAZw8rG0XjhEXAQEeOAaDHoEUBJ8ZizKDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,832,1384318800"; d="scan'208";a="42694892" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Feb 2014 08:53:26 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 12 Feb 2014 08:42:05 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 14:53:24 +0100 From: "Romascanu, Dan (Dan)" To: Thomas Nadeau , eman mailing list Thread-Topic: [eman] Read-Only or Read-Write EMAN MIBs Thread-Index: AQHPJ0LKAi3Xzvo/0kC6ip3cJ++yrZqxnqIg Date: Wed, 12 Feb 2014 13:53:24 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E403CD4@AZ-FFEXMB04.global.avaya.com> References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> In-Reply-To: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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, 12 Feb 2014 13:53:31 -0000 Hi, In a previous mail I expressed my opinion about removing the writable objec= ts of draft-ietf-eman-battery-mib-11. Here is my take on the other two documents. draft-ietf-eman-energy-aware-mib-14 already has conformance clauses for rea= d-only and read-write support. Folks should be aware that making the device= s readable only means that the configuration objects in the MIB module whic= h are about the reporting policies and domains will not be writeable via a = standard interface. I have no operational experience with energy management= to have an opinion if this makes sense or not.=20 draft-ietf-eman-energy-monitoring-mib-08 has two writable objects. I do not= understand well enough eoPowerStateEnterReason, in general I am no fan of = objects that pass information by writable strings, so I do not have a clear= opinion if it makes sense to make this object read-only or take it out. Th= e second object eoPowerEnableStatusNotification is a switch that activates = and de-activates notifications. Such MIB objects are not really configurati= on objects for the protocol or device, they rather configure the mode of wo= rk of the agents. I believe they can be left writable.=20 Regards, Dan > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Tuesday, February 11, 2014 6:03 PM > To: eman mailing list > Subject: [eman] Read-Only or Read-Write EMAN MIBs >=20 >=20 > EMAN WG: >=20 > The EMAN WG currently has three MIBs that are WG drafts: >=20 > draft-ietf-eman-battery-mib-11 > draft-ietf-eman-energy-aware-mib-14 > draft-ietf-eman-energy-monitoring-mib-08 >=20 > At present Benoit as AD, the Ops Directorate and MIB Doctors are > preparing a statement to WGs that strongly recommends against MIBs with > writable objects unless the working group has a strong consensus to do so= . > The current *draft* of the statement is listed here for your information: >=20 > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to use the > NETCONF/YANG standards for configuration, specifically in new charters. > SNMP MIB modules modifying persistent configuration state should only be > produced by working groups in cases of clear utility and overwhelming > consensus to use SNMP write operations for configuration. >=20 > In an effort to head off any potential snafus during the IESG review > of the three EMAN MIBs, I want to poll the WG for consensus on whether or > not to make the current list of WG documents read-write or read-only. If > there is not strong consensus to leave them read-write, Nevil and I will > instruct the editors to edit the documents to remove writable objects. >=20 > Please post comments on this matter by Friday, February 14, 2014 at > 9AM EDT. >=20 >=20 > Tom > EMAN WG Co-Chair >=20 >=20 From j.schoenwaelder@jacobs-university.de Wed Feb 12 06:50:16 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 6CBF11A09A5 for ; Wed, 12 Feb 2014 06:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 KPcJ2DEmVudy for ; Wed, 12 Feb 2014 06:50:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 282961A0340 for ; Wed, 12 Feb 2014 06:50:13 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20D222002A; Wed, 12 Feb 2014 15:50:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qoE4Gt13GwgH; Wed, 12 Feb 2014 15:50:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 813A520029; Wed, 12 Feb 2014 15:50:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 366AF2B45AA6; Wed, 12 Feb 2014 15:50:08 +0100 (CET) Date: Wed, 12 Feb 2014 15:50:08 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20140212145008.GA81278@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Thomas Nadeau , eman mailing list References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA2E403CD4@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E403CD4@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 14:50:16 -0000 On Wed, Feb 12, 2014 at 01:53:24PM +0000, Romascanu, Dan (Dan) wrote: > draft-ietf-eman-energy-monitoring-mib-08 has two writable objects. I do not understand well enough eoPowerStateEnterReason, in general I am no fan of objects that pass information by writable strings, so I do not have a clear opinion if it makes sense to make this object read-only or take it out. The second object eoPowerEnableStatusNotification is a switch that activates and de-activates notifications. Such MIB objects are not really configuration objects for the protocol or device, they rather configure the mode of work of the agents. I believe they can be left writable. Since the persistency of eoPowerEnableStatusNotification is not spelled out, it remains unclear whether this object is configuration or not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tnadeau@lucidvision.com Wed Feb 12 06:59:07 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 ACD141A09CB for ; Wed, 12 Feb 2014 06:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 eh4mADurIkUy for ; Wed, 12 Feb 2014 06:59:05 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A69981A09A9 for ; Wed, 12 Feb 2014 06:58:40 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A73B226EBF1C; Wed, 12 Feb 2014 09:58:39 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_1F1C1CE6-F2FC-4AB8-9B29-3449CA7AB624"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E403CD4@AZ-FFEXMB04.global.avaya.com> Date: Wed, 12 Feb 2014 09:58:38 -0500 Message-Id: References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA2E403CD4@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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, 12 Feb 2014 14:59:07 -0000 --Apple-Mail=_1F1C1CE6-F2FC-4AB8-9B29-3449CA7AB624 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 12, 2014:8:53 AM, at 8:53 AM, Romascanu, Dan (Dan) = wrote: > Hi, >=20 > In a previous mail I expressed my opinion about removing the writable = objects of draft-ietf-eman-battery-mib-11. >=20 > Here is my take on the other two documents. >=20 > draft-ietf-eman-energy-aware-mib-14 already has conformance clauses = for read-only and read-write support. Folks should be aware that making = the devices readable only means that the configuration objects in the = MIB module which are about the reporting policies and domains will not = be writeable via a standard interface. I have no operational experience = with energy management to have an opinion if this makes sense or not.=20 >=20 > draft-ietf-eman-energy-monitoring-mib-08 has two writable objects. I = do not understand well enough eoPowerStateEnterReason, in general I am = no fan of objects that pass information by writable strings, so I do not = have a clear opinion if it makes sense to make this object read-only or = take it out. The second object eoPowerEnableStatusNotification is a = switch that activates and de-activates notifications. Such MIB objects = are not really configuration objects for the protocol or device, they = rather configure the mode of work of the agents. I believe they can be = left writable.=20 =09 (Speaking without my chair hat on) But those switches and any other writable objects, do fall under = the concern being discussed which was that many/most operational = environments prohibit devices from implementing SNMP writes; therefore, = those objects, albeit relatively benign, will not be available either in = many environments.=20 --Tom >=20 > Regards, >=20 > Dan >=20 >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Tuesday, February 11, 2014 6:03 PM >> To: eman mailing list >> Subject: [eman] Read-Only or Read-Write EMAN MIBs >>=20 >>=20 >> EMAN WG: >>=20 >> The EMAN WG currently has three MIBs that are WG drafts: >>=20 >> draft-ietf-eman-battery-mib-11 >> draft-ietf-eman-energy-aware-mib-14 >> draft-ietf-eman-energy-monitoring-mib-08 >>=20 >> At present Benoit as AD, the Ops Directorate and MIB Doctors are >> preparing a statement to WGs that strongly recommends against MIBs = with >> writable objects unless the working group has a strong consensus to = do so. >> The current *draft* of the statement is listed here for your = information: >>=20 >> The OPS area recommends the use of NETCONF/YANG standards for >> configuration. IETF working groups are therefore encouraged to use = the >> NETCONF/YANG standards for configuration, specifically in new = charters. >> SNMP MIB modules modifying persistent configuration state should only = be >> produced by working groups in cases of clear utility and overwhelming >> consensus to use SNMP write operations for configuration. >>=20 >> In an effort to head off any potential snafus during the IESG = review >> of the three EMAN MIBs, I want to poll the WG for consensus on = whether or >> not to make the current list of WG documents read-write or read-only. = If >> there is not strong consensus to leave them read-write, Nevil and I = will >> instruct the editors to edit the documents to remove writable = objects. >>=20 >> Please post comments on this matter by Friday, February 14, 2014 = at >> 9AM EDT. >>=20 >>=20 >> Tom >> EMAN WG Co-Chair >>=20 >>=20 >=20 >=20 --Apple-Mail=_1F1C1CE6-F2FC-4AB8-9B29-3449CA7AB624 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS+4weAAoJEPcO+I7eiUJZtRIP/2PQUJ6xC0tjbpOLbkxRftQv ZZ9smxMTTB2MtX3bkb8RjiLKUbqwsjbpMhonOyetZV3Uy4GAywPPBFMPz2AaqXUS wTPq/1ETyZkvXLW8gKGN336YiRQXsK5Pmqe2zCMe8IX/peCrrg6ThphrCBlHHXjB FKghyTzjQSCmJcO2DdiJhOGrSruFxLpQCgj2ztZEff2ry2ip1rP0F3B6mnTGOXj3 kGbXs1zFieDBbbsEG71X8cFkeGryA07aLZAU4t6VTNPS3aw8hdfwzZda9KGqhOjW VLD/OTPefgqI/PaSn5Yl3Bwpp7gSYZcXMFEz7dZch2MEHbZJKf3nvUPToOsxYfEz 6gn9uSox3CxOVCJtlAKX74tsJ2MuV4I0u7XvgYZbj31KLoIP0i584h71qCKw12JR idX74IND3jt7WFauD1O+SfeMIzUE6xSkKYDKyJTUFwDvV8rwRYuaDfGaIgt3L5ol i7kfr5fAXKMOzXroxVM40R2HHUxnaPw6nBaTZkh7d0x/Gq4OpeQmzMySLkTVUPkf AQOu3bl00gqLnHrpvvxbBuRdMcfnHWPN6ZqFtnJJJR2I4wAjtBdIlsFwAjxYdfNr +ZfIewz9wjNlfN5/H274G5kq9IqU9LydCCj3tMf0Reb+4ER57+d1hYdH/9jUgTtB 8rxHIzLDk5vxy0fMiSUT =Y6Em -----END PGP SIGNATURE----- --Apple-Mail=_1F1C1CE6-F2FC-4AB8-9B29-3449CA7AB624-- From tnadeau@lucidvision.com Wed Feb 12 07:01:03 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 075DD1A0310 for ; Wed, 12 Feb 2014 07:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 GbjPWMkbogBZ for ; Wed, 12 Feb 2014 07:01:01 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3AC1A01DA for ; Wed, 12 Feb 2014 07:01:01 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 86FFD26EBF5F; Wed, 12 Feb 2014 10:01:00 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_ACEE417D-B89D-4C66-A662-3C3DB6C4D946"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <20140212145008.GA81278@elstar.local> Date: Wed, 12 Feb 2014 10:00:59 -0500 Message-Id: References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA2E403CD4@AZ-FFEXMB04.global.avaya.com> <20140212145008.GA81278@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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, 12 Feb 2014 15:01:03 -0000 --Apple-Mail=_ACEE417D-B89D-4C66-A662-3C3DB6C4D946 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 12, 2014:9:50 AM, at 9:50 AM, Juergen Schoenwaelder = wrote: > On Wed, Feb 12, 2014 at 01:53:24PM +0000, Romascanu, Dan (Dan) wrote: >=20 >> draft-ietf-eman-energy-monitoring-mib-08 has two writable objects. I = do not understand well enough eoPowerStateEnterReason, in general I am = no fan of objects that pass information by writable strings, so I do not = have a clear opinion if it makes sense to make this object read-only or = take it out. The second object eoPowerEnableStatusNotification is a = switch that activates and de-activates notifications. Such MIB objects = are not really configuration objects for the protocol or device, they = rather configure the mode of work of the agents. I believe they can be = left writable.=20 >=20 > Since the persistency of eoPowerEnableStatusNotification is not = spelled > out, it remains unclear whether this object is configuration or not. (Without my chair hat on) Differentiating between persistent configuration or = non-persistent is not going to matter if SNMP writes are operationally = disabled, are they? --Tom >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 --Apple-Mail=_ACEE417D-B89D-4C66-A662-3C3DB6C4D946 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS+4yrAAoJEPcO+I7eiUJZ25EP/RggU0fXGkPzetpB0Lv8U4hk dMbYREFllvQ3BXmgxd1cGIAVXZ2CHu+DUdrL3D/EYpJBhlH05nCtn6TcgO6DiG/l otUQ3DH3BfpKyx4cx7z1ZL0htPdXkMu33WaKVoHxxeHvFSPFq2PRllJRKMA6cS6F stzfTUPj8oEeMk7vOId+4dHOs7ED3lg9J1QY2hyfhU772qgIPwaWVBBGV4EynrbF PFOezf33hxp9Bz7MnUUSLIWAm1wz3OQ9BNtwNOhx5Sba9F8bMBqRriHzGnyUGFuQ bNPQPYbAg4wLC7rN2gfR8FCzjMrGbbQTvRIAs0tqR59Bl9UChHcuXbYSsJqseO7A NtZFVGDRXsoYuzwrNtSqWgXRs4ejnECV0+JRcNiHid34x3afVZthRhtliDi25Ua3 iUHhTqhjFEycwOhEuiAxQMS6oywgl40O0RlBxf435gbO89yWJ+i0Ed4FLiVXKpwl B0cBR91N02FDOhq3/dwx7FV1E4nu8CrJoUv/7lWCuNo06DHZVNMNdKOX/2Rzyb22 D4AAvDetaeAl4hdPMpTNkY0Tj3X3W7ddqkYn0W+KqZuBzHHik42HvsPZWxoIQLZi gbAP1xJ/48mUct3IdWyLItekNiZ74CJVyUhMs12i0vz/9UX/+m5C+tfKUjcDy7zn P0MxNZI21GaDOiFwCVyj =reGT -----END PGP SIGNATURE----- --Apple-Mail=_ACEE417D-B89D-4C66-A662-3C3DB6C4D946-- From j.schoenwaelder@jacobs-university.de Wed Feb 12 07:19:03 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 7E9CA1A046A for ; Wed, 12 Feb 2014 07:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 RRDf2Bqc-Kkh for ; Wed, 12 Feb 2014 07:19:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D5B731A0398 for ; Wed, 12 Feb 2014 07:19:00 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE7E720032; Wed, 12 Feb 2014 16:18:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QvJu6LfQtXk4; Wed, 12 Feb 2014 16:18:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 061CE20030; Wed, 12 Feb 2014 16:18:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ACE732B45CFE; Wed, 12 Feb 2014 16:18:57 +0100 (CET) Date: Wed, 12 Feb 2014 16:18:57 +0100 From: Juergen Schoenwaelder To: Thomas Nadeau Message-ID: <20140212151857.GB81367@elstar.local> Mail-Followup-To: Thomas Nadeau , "Romascanu, Dan (Dan)" , eman mailing list References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA2E403CD4@AZ-FFEXMB04.global.avaya.com> <20140212145008.GA81278@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 mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 15:19:03 -0000 On Wed, Feb 12, 2014 at 10:00:59AM -0500, Thomas Nadeau wrote: > > On Feb 12, 2014:9:50 AM, at 9:50 AM, Juergen Schoenwaelder wrote: > > > On Wed, Feb 12, 2014 at 01:53:24PM +0000, Romascanu, Dan (Dan) wrote: > > > >> draft-ietf-eman-energy-monitoring-mib-08 has two writable objects. I do not understand well enough eoPowerStateEnterReason, in general I am no fan of objects that pass information by writable strings, so I do not have a clear opinion if it makes sense to make this object read-only or take it out. The second object eoPowerEnableStatusNotification is a switch that activates and de-activates notifications. Such MIB objects are not really configuration objects for the protocol or device, they rather configure the mode of work of the agents. I believe they can be left writable. > > > > Since the persistency of eoPowerEnableStatusNotification is not spelled > > out, it remains unclear whether this object is configuration or not. > > (Without my chair hat on) > > Differentiating between persistent configuration or non-persistent is not going to matter if SNMP writes are operationally disabled, are they? > Frankly, the fact that ISPs do not SNMP write does not mean SNMP writes do not exist. Read the security horror stories about SCADA networks. SNMP has a significant share there and perhaps we would wish things are not writable. ;-) My understanding is that the EMAN work targets deployments most likely in enterprise networks. And I think it is also bad style to cast a new policy (which is BTW not set in stone yet either) and to tell WGs that have been working on something for years to suddenly change their documents. The WG needs to decide. If there is concensus to get rid of writable objects, fine. My only take is that if you have writable objects, you need to spell out the persistency propoerties. RFC 4181 page 20: For read-write objects (other than columns in read-create tables that have well-defined persistence properties), it is RECOMMENDED that the DESCRIPTION clause specify what happens to the value after an agent reboot. Among the possibilities are that the value remains unchanged, that it reverts to a well-defined default value, or that the result is implementation-dependent. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tnadeau@lucidvision.com Wed Feb 12 07:26:03 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 37D101A0425 for ; Wed, 12 Feb 2014 07:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 AoqStIZbTcli for ; Wed, 12 Feb 2014 07:26:01 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C2E381A0310 for ; Wed, 12 Feb 2014 07:26:00 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A792026EC0A9; Wed, 12 Feb 2014 10:25:59 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_31BFC801-DACE-4E6B-B411-CBE6ADFAE479"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <20140212151857.GB81367@elstar.local> Date: Wed, 12 Feb 2014 10:25:59 -0500 Message-Id: <634AB133-E615-4E27-8BBA-0903734D66CF@lucidvision.com> References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA2E403CD4@AZ-FFEXMB04.global.avaya.com> <20140212145008.GA81278@elstar.local> <20140212151857.GB81367@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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, 12 Feb 2014 15:26:03 -0000 --Apple-Mail=_31BFC801-DACE-4E6B-B411-CBE6ADFAE479 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 12, 2014:10:18 AM, at 10:18 AM, Juergen Schoenwaelder = wrote: > On Wed, Feb 12, 2014 at 10:00:59AM -0500, Thomas Nadeau wrote: >>=20 >> On Feb 12, 2014:9:50 AM, at 9:50 AM, Juergen Schoenwaelder = wrote: >>=20 >>> On Wed, Feb 12, 2014 at 01:53:24PM +0000, Romascanu, Dan (Dan) = wrote: >>>=20 >>>> draft-ietf-eman-energy-monitoring-mib-08 has two writable objects. = I do not understand well enough eoPowerStateEnterReason, in general I am = no fan of objects that pass information by writable strings, so I do not = have a clear opinion if it makes sense to make this object read-only or = take it out. The second object eoPowerEnableStatusNotification is a = switch that activates and de-activates notifications. Such MIB objects = are not really configuration objects for the protocol or device, they = rather configure the mode of work of the agents. I believe they can be = left writable.=20 >>>=20 >>> Since the persistency of eoPowerEnableStatusNotification is not = spelled >>> out, it remains unclear whether this object is configuration or not. >>=20 >> (Without my chair hat on) >>=20 >> Differentiating between persistent configuration or = non-persistent is not going to matter if SNMP writes are operationally = disabled, are they? >>=20 >=20 > Frankly, the fact that ISPs do not SNMP write does not mean SNMP > writes do not exist. Read the security horror stories about SCADA > networks. SNMP has a significant share there and perhaps we would > wish things are not writable. ;-) My understanding is that the EMAN > work targets deployments most likely in enterprise networks. (chair hat off) =09 Power distribution networks are I guess a type of enterprise = network but there are definitely "wan" cases too such as the smart grid work I = did=20 a bit of at BT. In these cases you often have much tighter security = constraints=20 to prevent unwanted tampering or worse - disconnecting the power. *) > And I > think it is also bad style to cast a new policy (which is BTW not set > in stone yet either) and to tell WGs that have been working on > something for years to suddenly change their documents. > The WG needs to decide. If there is concensus to get rid of writable > objects, fine. My only take is that if you have writable objects, you > need to spell out the persistency propoerties. >=20 > RFC 4181 page 20: >=20 > For read-write objects (other than columns in read-create tables = that > have well-defined persistence properties), it is RECOMMENDED that = the > DESCRIPTION clause specify what happens to the value after an agent > reboot. Among the possibilities are that the value remains > unchanged, that it reverts to a well-defined default value, or that > the result is implementation-dependent. That is a very good point.=20 --Tom >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 --Apple-Mail=_31BFC801-DACE-4E6B-B411-CBE6ADFAE479 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS+5KHAAoJEPcO+I7eiUJZDEEP/3nBhnzkF4pnlVTFj/I2kkpg jIPdZ/emcerpSmSlIhw8z5jWx0RHrxyVpmpO3qMx5NsCb6YpxsmWjFWrIg2gYiYS WRW39CncUe0DMRcJGGnOr0UHRWZo9C9bIOkgTPho6Zt8zPfw1CHMXvZD22iThm/j 1lOMdo0/ZoQwsnLtoaviaWt+gU7Mg2razyOUgP6Ed5zFggCE1jMK85NwLStUpEjL GqTRS1hmLWXnh5ec03EhFssgZjRThQdzoRblxvHKKsKojXODWbRz3q5HKBnH1/+l 6GgY5Zkgq3p0rODEFeT/TTvJnY/1LGdl0pNl0GoVstsXV4VIJpijOcrJGjGb/Ywj 8bmJpRos0ybjy/fwnBh9vFQ1evapdXdJJRV0uqf4M+saCZvRsOIzX1pH1KpwJkBw AM5MMAl1Hy5xOaF8xIKlujaReZ9uCy9tAEzeZqQhjytybFuW4H7veNUt5qdLnvPX BtqoESeeEhTcxq+MD8UMvV86LlZHUyCnaZReTFSnF5y0zPRYqq+dmJbTizSJoEjG CXoSld9ZB5U9m7kF+DkmIpw9rsLbLfI5VonpmUKyuOw4qDrKuiHTKx/3d25tVZnm 97Df1TTwS7iVzZ/wsinWl53HoXFlyyomQV6K38xoTvHoMvOS6zhNVtReRnjdmS6A cHEpcejt3Ag21Nsls1Y2 =egD8 -----END PGP SIGNATURE----- --Apple-Mail=_31BFC801-DACE-4E6B-B411-CBE6ADFAE479-- From nobody Thu Feb 13 17:41:28 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 F29F31A001B for ; Thu, 13 Feb 2014 17:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 Cdowr85fUaQ4 for ; Thu, 13 Feb 2014 17:41:23 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 966421A0016 for ; Thu, 13 Feb 2014 17:41:23 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E4A6726EFBB7 for ; Thu, 13 Feb 2014 20:41:21 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_F1065DF2-D9AD-41D4-965F-DDCB9053E94A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 13 Feb 2014 20:41:21 -0500 References: <52FD65DD.4090609@cisco.com> To: eman mailing list Message-Id: <7D762755-7594-4865-82C0-5E2677D6BB35@lucidvision.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/eman/MbN116E4kY9_wCcdty1qUg0j6ak Subject: [eman] Fwd: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules 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: Fri, 14 Feb 2014 01:41:26 -0000 --Apple-Mail=_F1065DF2-D9AD-41D4-965F-DDCB9053E94A Content-Type: multipart/alternative; boundary="Apple-Mail=_CD172BDC-C8E4-45A3-B43B-787B84E7662F" --Apple-Mail=_CD172BDC-C8E4-45A3-B43B-787B84E7662F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FYI in case you are not on the opsdir list... Begin forwarded message: > From: Benoit Claise > Subject: [OPS-AREA] configuration: writable MIB modules versus = NETCONF/YANG modules > Date: February 13, 2014 at 7:39:57 PM EST > To: "ops-area@ietf.org" >=20 > Dear all, >=20 > We occasionally see read-write MIB module proposals within the IETF. > However, the write capabilities of those MIB modules are rarely = implemented. >=20 > While discussing this issue with the MIB doctors, we arrive to the = conclusion that it's now time to set the direction for future MIB = developments within the IETF. Basically, let's not specify read-write = MIB modules unless we have a good reason. Read-only MIB modules are = still fine though, as SNMP is clearly used for monitoring purposes. >=20 > Here is the statement we came up with: > The OPS area recommends the use of NETCONF/YANG standards for = configuration. IETF working groups are therefore encouraged to use the = NETCONF/YANG standards for configuration, specifically in new charters. = SNMP MIB modules modifying persistent configuration state should only be = produced by working groups in cases of clear utility=20 > and consensus to use SNMP write operations for configuration. > Ideally, this should become an IESG statement. > Your feedback is most welcome. >=20 > Regards, the MIB doctors & Benoit >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area --Apple-Mail=_CD172BDC-C8E4-45A3-B43B-787B84E7662F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

FYI in case you are not on the = opsdir list...

Begin forwarded message:

From: Benoit Claise <bclaise@cisco.com>
Subject: [OPS-AREA] configuration: writable = MIB modules versus NETCONF/YANG modules
Date: February 13, 2014 at 7:39:57 PM = EST
To: = "ops-area@ietf.org" <ops-area@ietf.org>

=20 =20
Dear all,

We occasionally see read-write MIB module proposals within the = IETF.
However, the write capabilities of those MIB modules are rarely implemented.

While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes.

Here is the statement we came up with:
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility
and consensus to use SNMP write operations for configuration.
Ideally, this should become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit

_______________________________________________
OPS-AREA mailing = list
OPS-AREA@ietf.org
https://www.iet= f.org/mailman/listinfo/ops-area

= --Apple-Mail=_CD172BDC-C8E4-45A3-B43B-787B84E7662F-- --Apple-Mail=_F1065DF2-D9AD-41D4-965F-DDCB9053E94A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS/XRBAAoJEPcO+I7eiUJZE04P/3vRUpa9KpBHShS5jCKssREn YmueWwAA3vyyRu5qwdJG0lBvs0YaJ5ng+wxnAPyM08gxLCouoxSvZ61eoK+FHorE MZpXmJ5Yfs9nF0KY7Ld7QHBD3kPCIq/G4bo3qZUtOwefxp8HH/GXK5IpamhOSM1K 2KWakQ2dKYYjgsHUgfCmMKTbWYboXoORRO+IR3bTsAOmUxmxwS4ROWTUV8hGVJwJ Vp7oovn7vN+RiBvjzNzSZxbkTZeHtVkFp2zz5NFhyka9yHYWJoER+OaXLvUomuZ5 I5sB6iPoBS2Hs45CtjPjlN4wHh1arIa/iuKEIY+4WBV9XdaunIJr1LiR1W8XVi3z ZXiUu1yAy4aLTHbV7fuNLbCfvb/m5av5VBd2ML+hiiciFH5ShFT+y65k6UTAT76l +3P7rg8Ux6ryCHh5/7sErJxKZBQboraPCat6mcF8rI2fJ5iAPZqfbzL8PDUaEfbL fj1M3CLPYu23a8eiw3mZ0GJNNh38epgWHC59WqmCixjdG91RyPoSpIwvfzD49LzZ a48FsjyJ45Euk3o39aBvaQF9nvHaGOAOwZbxeMhAkxNo6gg2FF39Qm+hsbV0+LXL XDbNRY1WOHrXyIuZmTE7+kKCuA0O1DHxUKMFm1q5dKclgXb2bU6EVPAuOKShefOR 4Fv0ZNKSRgOwxW5Sbpy/ =IyZJ -----END PGP SIGNATURE----- --Apple-Mail=_F1065DF2-D9AD-41D4-965F-DDCB9053E94A-- From nobody Fri Feb 14 00:07:37 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 F2BAA1A011E for ; Fri, 14 Feb 2014 00:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 Nfp4laxCE3sC for ; Fri, 14 Feb 2014 00:07:27 -0800 (PST) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 078A51A0121 for ; Fri, 14 Feb 2014 00:07:26 -0800 (PST) X-Ironport-SBRS: 4.8 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQDAL3N/VLRVdgvlGdsb2JhbABWA4JCfFe2XohVgQ4IFg4BAQEBBwsLCRIqgiUBAQEDAQEBAWsLEAsEBwM4IgUNAQUBHAYTh30IBQibB64GF44RWAwEBxGEJwSJSI5kgTKPBBgphHob X-IronPort-AV: E=Sophos;i="4.95,843,1384329600"; d="scan'208";a="40452705" Received: from mail-qa0-f47.google.com ([209.85.216.47]) by fe1.lbl.gov with ESMTP; 14 Feb 2014 00:07:24 -0800 Received: by mail-qa0-f47.google.com with SMTP id j5so17503435qaq.6 for ; Fri, 14 Feb 2014 00:07:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qab1AUfkz48vQDcr27NjfuO4v+Ppflvw2BVWOoyaIsY=; b=BbW8YYAk56M9wg0lTcrGD1Weq594gKCCl7OqCVe1y6FXOlZlOoa+zfid3Ak/X5iz/M f3G9JVG4TRxBKo6J33HjqaNCVhjGj94OjdAVgbFuNuUyHnQvhWG5AraCEwVFP9jDLeUG yvKoGyOhkgBgowcdGw7yf+DgWzy8v7IqQrrzfmqVRlzElRppIYYpFpPm/9Ov/jQIIVyd N4g11rJqeipJ5Nk7tUnD7YFct8f3bqV3u8jmYOW0P9f92baf2s98YjUrohmhmYUw1i7t wtBpMugYa6vsiNY7B6F7ENHClXiEXkcheV2evMzBraa6xPqm48aeP8JAJrEzd9t54KoH 3Drg== X-Gm-Message-State: ALoCoQmD1B5mmPF7PgeIDxTqSYNZOgptFIDz+x5cxGIed+CV1LRNWrwZolvve9/OCEgVDAAz23vdIwktPHGAnxUorbvXhhZoVqm9oO0jDN6U8+FaWul9ym0ASHWsqZSb4evfCGpMvs6e X-Received: by 10.140.81.74 with SMTP id e68mr9758544qgd.99.1392365244736; Fri, 14 Feb 2014 00:07:24 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.81.74 with SMTP id e68mr9758532qgd.99.1392365244594; Fri, 14 Feb 2014 00:07:24 -0800 (PST) Received: by 10.140.29.229 with HTTP; Fri, 14 Feb 2014 00:07:24 -0800 (PST) In-Reply-To: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> Date: Fri, 14 Feb 2014 00:07:24 -0800 Message-ID: From: Bruce Nordman To: Thomas Nadeau Content-Type: multipart/alternative; boundary=001a11c11d12cd67c404f2594b23 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/o_ynWvU2qqRoradeOLNJtOf16Vo Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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: Fri, 14 Feb 2014 08:07:30 -0000 --001a11c11d12cd67c404f2594b23 Content-Type: text/plain; charset=ISO-8859-1 Since EMAN is to be used for any type of energy-using device - a vastly larger set than network equipment - I think it premature to rule out using SNMP for writing data to devices. I don't think this undermines the principle of not doing so for purposes of general network management. --Bruce On Tue, Feb 11, 2014 at 8:02 AM, Thomas Nadeau wrote: > > EMAN WG: > > The EMAN WG currently has three MIBs that are WG drafts: > > draft-ietf-eman-battery-mib-11 > draft-ietf-eman-energy-aware-mib-14 > draft-ietf-eman-energy-monitoring-mib-08 > > At present Benoit as AD, the Ops Directorate and MIB Doctors are > preparing a statement to WGs that strongly recommends against MIBs with > writable objects unless the working group has a strong consensus to do so. > The current *draft* of the statement is listed here for your information: > > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to use > the NETCONF/YANG standards for configuration, specifically in new > charters. SNMP MIB modules modifying persistent configuration state > should only be produced by working groups in cases of clear utility and > overwhelming consensus to use SNMP write operations for configuration. > > In an effort to head off any potential snafus during the IESG > review > of the three EMAN MIBs, I want to poll the WG for consensus on whether or > not > to make the current list of WG documents read-write or read-only. If there > is > not strong consensus to leave them read-write, Nevil and I will instruct > the > editors to edit the documents to remove writable objects. > > Please post comments on this matter by Friday, February 14, 2014 > at 9AM EDT. > > > Tom > EMAN WG Co-Chair > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov * BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --001a11c11d12cd67c404f2594b23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Since EMAN is to be used for any type of energy-using=
device - a vastly larger set than network equipment - I
think it pre= mature to rule out using SNMP for writing
data to devices.=A0 I don'= t think this undermines the principle
of not doing so for purposes of general network management.

--= Bruce


On Tue, Feb 11, 2014 at 8:02 AM, Thomas Nadeau <tnadeau@lucidvisio= n.com> wrote:

=A0 =A0 =A0 =A0 EMAN WG:

=A0 =A0 =A0 =A0 The EMAN WG currently has three MIBs that are WG drafts:
=A0 =A0 =A0 =A0 draft-ietf-eman-battery-mib-11
=A0 =A0 =A0 =A0 draft-ietf-eman-energy-aware-mib-14
=A0 =A0 =A0 =A0 draft-ietf-eman-energy-monitoring-mib-08

=A0 =A0 =A0 =A0 At present Benoit as AD, the Ops Directorate and MIB Doctor= s are preparing a statement to WGs that strongly recommends against MIBs wi= th writable objects unless the working group has a strong consensus to do s= o. The current *draft* of the statement is listed here for your information= :

The OPS area recommends the use of NETCONF/YANG standards for
configuration. IETF working groups are therefore encouraged to use
the NETCONF/YANG standards for configuration, specifically in new
charters. SNMP MIB modules modifying persistent configuration state
should only be produced by working groups in cases of clear utility and
overwhelming consensus to use SNMP write operations for configuration.

=A0 =A0 =A0 =A0 In an effort to head off any potential snafus during the IE= SG review
of the three EMAN MIBs, I want to poll the WG for consensus on whether or n= ot
to make the current list of WG documents read-write or read-only. If there = is
not strong consensus to leave them read-write, Nevil and I will instruct th= e
editors to edit the documents to remove writable objects.

=A0 =A0 =A0 =A0 Please post comments on this matter by Friday, February 14,= 2014
at 9AM EDT.


=A0 =A0 =A0 =A0 Tom
=A0 =A0 =A0 =A0 EMAN WG Co-Chair




_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman




--
Bruce Nordman
Lawrence Be= rkeley National Laboratory
= nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--001a11c11d12cd67c404f2594b23-- From nobody Fri Feb 14 19:57:54 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 B40051A0005 for ; Fri, 14 Feb 2014 19:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 y_r_BEzWjEFG for ; Fri, 14 Feb 2014 19:57:51 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id E8F871A0004 for ; Fri, 14 Feb 2014 19:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5176; q=dns/txt; s=iport; t=1392436669; x=1393646269; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bILEJ5jswlCVf2aTrgirOYDDkw6bqTZB3fW8CVhwTi4=; b=jgag9C563qSIOMxVmxr2pNskmKH8psrNNuUNEjZptKbBm0XeQ33/zEgX vfccaM5Txivsp5bIGkqueWXzYbyAh/HMgg2ffdnUzZhWcElyKhrwNVR/a lkI9Uy2G76btxivIwKXq2D5mp2b+a10+2Kn9YFVd3LLDvZGniMjX0CJFZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAOHk/lKtJV2c/2dsb2JhbABZgkJEgQ+/M4EXFnSCJgEBBIEJAgEIDjgyJQIEAYgXyQoXjhNvhDgEmCySI4Mtgio X-IronPort-AV: E=Sophos; i="4.95,849,1384300800"; d="scan'208,217"; a="20658243" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 15 Feb 2014 03:57:48 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1F3vmee030833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Feb 2014 03:57:49 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.84]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 21:57:48 -0600 From: "Mouli Chandramouli (moulchan)" To: Thomas Nadeau , eman mailing list Thread-Topic: [eman] Read-Only or Read-Write EMAN MIBs Thread-Index: AQHPJ0LLiUdR8nzsokKQyABm8S9ZoJq2dm4A Date: Sat, 15 Feb 2014 03:57:47 +0000 Message-ID: References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> In-Reply-To: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.62.190] Content-Type: multipart/alternative; boundary="_000_CF24E3481E9FFmoulchanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/IioCHkpZbR5LFRQyYTOLOIhVuNU Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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: Sat, 15 Feb 2014 03:57:52 -0000 --_000_CF24E3481E9FFmoulchanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have read-only implementations of the EMAN-MIB on Cisco platforms as a f= irst step towards reporting. Thanks Mouli EMAN WG: The EMAN WG currently has three MIBs that are WG drafts: draft-ietf-eman-battery-mib-11 draft-ietf-eman-energy-aware-mib-14 draft-ietf-eman-energy-monitoring-mib-08 At present Benoit as AD, the Ops Directorate and MIB Doctors are preparing = a statement to WGs that strongly recommends against MIBs with writable obje= cts unless the working group has a strong consensus to do so. The current *= draft* of the statement is listed here for your information: The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility and overwhelming consensus to use SNMP write operations for configuration. In an effort to head off any potential snafus during the IESG review of the three EMAN MIBs, I want to poll the WG for consensus on whether or n= ot to make the current list of WG documents read-write or read-only. If there = is not strong consensus to leave them read-write, Nevil and I will instruct th= e editors to edit the documents to remove writable objects. Please post comments on this matter by Friday, February 14, 2014 at 9AM EDT. Tom EMAN WG Co-Chair --_000_CF24E3481E9FFmoulchanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <85D1D8CACF0E6C489B06C3BD9719C6F3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

We have read-only implementations of the EMAN-MIB on Cisco platforms a= s a first step towards reporting. 

Thanks
Mouli

EMAN W= G:

The EM= AN WG currently has three MIBs that are WG drafts:

draft-= ietf-eman-battery-mib-11
draft-= ietf-eman-energy-aware-mib-14
draft-= ietf-eman-energy-monitoring-mib-08

At pre= sent Benoit as AD, the Ops Directorate and MIB Doctors are preparing a stat= ement to WGs that strongly recommends against MIBs with writable objects un= less the working group has a strong consensus to do so. The current *draft* of the statement is listed here fo= r your information:

The OPS area recommends the use of NETCONF/YANG standards for
configuration. IETF working groups are therefore encouraged to use
the NETCONF/YANG standards for configuration, specifically in new
charters. SNMP MIB modules modifying persistent configuration state
should only be produced by working groups in cases of clear utility an= d
overwhelming consensus to use SNMP write operations for configuration.=

In an = effort to head off any potential snafus during the IESG review
of the three EMAN MIBs, I want to poll the WG for consensus on whether= or not
to make the current list of WG documents read-write or read-only. If t= here is
not strong consensus to leave them read-write, Nevil and I will instru= ct the
editors to edit the documents to remove writable objects.

Please= post comments on this matter by Friday, February 14, 2014
at 9AM EDT.


Tom
EMAN W= G Co-Chair




--_000_CF24E3481E9FFmoulchanciscocom_-- From nobody Sun Feb 16 14:43:25 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 DE1981A02D9 for ; Sun, 16 Feb 2014 14:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 F-3P8aCX5Iwc for ; Sun, 16 Feb 2014 14:43:20 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB41A0278 for ; Sun, 16 Feb 2014 14:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1392590598; x=1424126598; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=VYs2htuhRdXTBQxOBoRbt4aG3SzrE4ZVgGD5ygvpwMw=; b=uLsLrT1A8IR1/nDADBbcKm2KId7hMVNSzsyVBEKbQyhiFj5X1oRBLK/f L/Q0MejD65Mz0Q/G/J4yhGcF4JZ5Z7hrGkov++PJH4Yx+MePue20XJ6pz 9x90OC/NjWPCjq1yHn7QKDfWVdzHj7tm2ZisY24OWCWVfK6M965LOezYZ U=; X-IronPort-AV: E=Sophos;i="4.95,857,1384254000"; d="scan'208";a="234592260" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 17 Feb 2014 11:43:11 +1300 Message-ID: <53013EF3.1000407@auckland.ac.nz> Date: Mon, 17 Feb 2014 11:42:59 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "eman@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/eman/aJoGzdFVY3p2PappfZ-dcMHwHlI Subject: [eman] Agenda for EMAN meeting at IETF-89, London 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: Sun, 16 Feb 2014 22:43:23 -0000 Hi all: I've put the EMAN agenda online, you can see it by clicking on 'Energy Management' at the right-hand side of the meeting agenda web page. Draft authors: please let me know who will be presenting your draft sometime soon so that I can update the agenda. Also, please note that our session is on Monday afternoon - I'll need your slides one or two days before that so that I can put them up on the Meeting Materials page. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Mon Feb 17 00:42:54 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 65F641A011B for ; Mon, 17 Feb 2014 00:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 qbwJ5uzBadS4 for ; Mon, 17 Feb 2014 00:42:50 -0800 (PST) Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) by ietfa.amsl.com (Postfix) with ESMTP id 264D51A00BE for ; Mon, 17 Feb 2014 00:42:49 -0800 (PST) Received: from t530shadow (p549C40ED.dip0.t-ipconnect.de [84.156.64.237]) (authenticated bits=0) by mailgw1.uni-kl.de (8.14.3/8.14.3/Debian-9.4) with ESMTP id s1H8giZ3010572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 09:42:45 +0100 From: "David Prantl" To: "'Thomas Nadeau'" , "'eman mailing list'" References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> In-Reply-To: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> Date: Mon, 17 Feb 2014 09:42:45 +0100 Message-ID: <001801cf2bbc$3b43f870$b1cbe950$@prantl.name> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHC6u7uBAKsxvXaYoAFJCbQSShBjJrRolsw Content-Language: de Archived-At: http://mailarchive.ietf.org/arch/msg/eman/vSOtCMFXF8UK-JQNUVkbKChEGd0 Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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: Mon, 17 Feb 2014 08:42:52 -0000 Hi, Currently the Cisco Energywise Manager/Joulex Energy Manager only has been used with read-only implementations of the EMAN-MIB. Thanks Mouli -----Original Message----- From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: Dienstag, 11. Februar 2014 17:03 To: eman mailing list Subject: [eman] Read-Only or Read-Write EMAN MIBs EMAN WG: The EMAN WG currently has three MIBs that are WG drafts: draft-ietf-eman-battery-mib-11 draft-ietf-eman-energy-aware-mib-14 draft-ietf-eman-energy-monitoring-mib-08 At present Benoit as AD, the Ops Directorate and MIB Doctors are preparing a statement to WGs that strongly recommends against MIBs with writable objects unless the working group has a strong consensus to do so. The current *draft* of the statement is listed here for your information: The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility and overwhelming consensus to use SNMP write operations for configuration. In an effort to head off any potential snafus during the IESG review of the three EMAN MIBs, I want to poll the WG for consensus on whether or not to make the current list of WG documents read-write or read-only. If there is not strong consensus to leave them read-write, Nevil and I will instruct the editors to edit the documents to remove writable objects. Please post comments on this matter by Friday, February 14, 2014 at 9AM EDT. Tom EMAN WG Co-Chair From nobody Mon Feb 17 01:00:45 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 036EA1A0394 for ; Mon, 17 Feb 2014 01:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 Si5OpQWIjtm5 for ; Mon, 17 Feb 2014 01:00:42 -0800 (PST) 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 B843E1A02C3 for ; Mon, 17 Feb 2014 01:00:41 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANbOAVPGmAcV/2dsb2JhbABZgmUhOFe/M4EaFnSCJQEBAQEDAQEBDyg0FwQCAQgNBAQBAQsUCQcnCxQJCAIEARIIGodjAQyfNKwIEwSOGTc4BoMegRQEnxuLNIMtgio X-IronPort-AV: E=Sophos;i="4.95,859,1384318800"; d="scan'208";a="43196340" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Feb 2014 04:00:37 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 17 Feb 2014 03:48:58 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 10:00:35 +0100 From: "Romascanu, Dan (Dan)" To: David Prantl , 'Thomas Nadeau' , 'eman mailing list' Thread-Topic: [eman] Read-Only or Read-Write EMAN MIBs Thread-Index: AQHC6u7uBAKsxvXaYoAFJCbQSShBjJrRolswgAAD1SA= Date: Mon, 17 Feb 2014 09:00:34 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E41B63A@AZ-FFEXMB04.global.avaya.com> References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <001801cf2bbc$3b43f870$b1cbe950$@prantl.name> In-Reply-To: <001801cf2bbc$3b43f870$b1cbe950$@prantl.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/njNJNFY-B11bXLapcd0wDJZ1eMk Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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: Mon, 17 Feb 2014 09:00:44 -0000 Hi David, I have a question about the read-only implementation of draft-ietf-eman-bat= tery-mib . There are six writeable objects in the MIB module batteryAlarmLo= wCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighC= ycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature which se= t thresholds for notifications. In a read-only implementation how are these= objects set - using CLI instead and then the MIB objects are used to displ= ay the values set by CLI? Or you do not do notifications at all?=20 Thanks and Regards, Dan > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of David Prantl > Sent: Monday, February 17, 2014 10:43 AM > To: 'Thomas Nadeau'; 'eman mailing list' > Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs >=20 > Hi, >=20 > Currently the Cisco Energywise Manager/Joulex Energy Manager only has > been used with read-only implementations of the EMAN-MIB. >=20 > Thanks > Mouli >=20 >=20 > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Dienstag, 11. Februar 2014 17:03 > To: eman mailing list > Subject: [eman] Read-Only or Read-Write EMAN MIBs >=20 >=20 > EMAN WG: >=20 > The EMAN WG currently has three MIBs that are WG drafts: >=20 > draft-ietf-eman-battery-mib-11 > draft-ietf-eman-energy-aware-mib-14 > draft-ietf-eman-energy-monitoring-mib-08 >=20 > At present Benoit as AD, the Ops Directorate and MIB Doctors are > preparing a statement to WGs that strongly recommends against MIBs with > writable objects unless the working group has a strong consensus to do so= . > The current *draft* of the statement is listed here for your information: >=20 > The OPS area recommends the use of NETCONF/YANG standards for > configuration. > IETF working groups are therefore encouraged to use the NETCONF/YANG > standards for configuration, specifically in new charters. SNMP MIB modul= es > modifying persistent configuration state should only be produced by worki= ng > groups in cases of clear utility and overwhelming consensus to use SNMP > write operations for configuration. >=20 > In an effort to head off any potential snafus during the IESG review > of the three EMAN MIBs, I want to poll the WG for consensus on whether or > not to make the current list of WG documents read-write or read-only. If > there is not strong consensus to leave them read-write, Nevil and I will > instruct the editors to edit the documents to remove writable objects. >=20 > Please post comments on this matter by Friday, February 14, 2014 at > 9AM EDT. >=20 >=20 > Tom > EMAN WG Co-Chair >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From nobody Mon Feb 17 01:10:39 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 8F0211A00B6 for ; Mon, 17 Feb 2014 01:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] 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 cmC5OUdd0kXm for ; Mon, 17 Feb 2014 01:10:35 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2960F1A00C6 for ; Mon, 17 Feb 2014 01:10:35 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DF1F8FCB; Mon, 17 Feb 2014 10:10:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Dxh373vgk5Yt; Mon, 17 Feb 2014 10:10:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Mon, 17 Feb 2014 10:10:30 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B6E820029; Mon, 17 Feb 2014 10:10:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wQQP9ieOULsX; Mon, 17 Feb 2014 10:10:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBAD320026; Mon, 17 Feb 2014 10:10:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ECBB02B544FE; Mon, 17 Feb 2014 10:10:27 +0100 (CET) Date: Mon, 17 Feb 2014 10:10:27 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20140217091027.GA96287@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Prantl , 'Thomas Nadeau' , 'eman mailing list' References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <001801cf2bbc$3b43f870$b1cbe950$@prantl.name> <9904FB1B0159DA42B0B887B7FA8119CA2E41B63A@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E41B63A@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/eman/u7QrHNN5Zf7OWTmMEUQdmRCeunM Cc: 'eman mailing list' Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 17 Feb 2014 09:10:38 -0000 On Mon, Feb 17, 2014 at 09:00:34AM +0000, Romascanu, Dan (Dan) wrote: > Hi David, > > I have a question about the read-only implementation of draft-ietf-eman-battery-mib . There are six writeable objects in the MIB module batteryAlarmLowCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighCycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature which set thresholds for notifications. In a read-only implementation how are these objects set - using CLI instead and then the MIB objects are used to display the values set by CLI? Or you do not do notifications at all? > The batteryCompliance seems to allow both options. You are not required to implement batteryAlarmThresholdsGroup. If you choose to do so, you are not required to implement the objects read-write. Of course, if you support threshold notifications and implement read-only, the parameters must be set via some other mechanism. It may make sense to make the threshold objects conditionally mandatory to implement (at least read-only) if the batteryNotificationsGroup is implemented so that management applications can see the thresholds generating the notifications. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Feb 17 02:06:00 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 C66E51A0453 for ; Mon, 17 Feb 2014 02:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 i_O8E8WVYVF5 for ; Mon, 17 Feb 2014 02:05:55 -0800 (PST) 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 5558C1A03C9 for ; Mon, 17 Feb 2014 02:05:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgILAGHeAVOHCzIm/2dsb2JhbABWA4JlIThXqAqXKoEcFnSCJQEBAQEDEig0CwwCAgIBCA0BAgEEAQEBChQJBxsXFAkIAgQODRqHYwGfP6wLFwSOFTchEAcGC4MTgRQEmV6FPYs0gy2CKg X-IronPort-AV: E=Sophos;i="4.95,859,1384318800"; d="scan'208";a="49813473" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Feb 2014 05:05:52 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 17 Feb 2014 04:53:00 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 05:05:50 -0500 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [eman] Read-Only or Read-Write EMAN MIBs Thread-Index: AQHC6u7uBAKsxvXaYoAFJCbQSShBjJrRolswgAAD1SD///NggIAAH+ZA Date: Mon, 17 Feb 2014 10:05:50 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E41B759@AZ-FFEXMB04.global.avaya.com> References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <001801cf2bbc$3b43f870$b1cbe950$@prantl.name> <9904FB1B0159DA42B0B887B7FA8119CA2E41B63A@AZ-FFEXMB04.global.avaya.com> <20140217091027.GA96287@elstar.local> In-Reply-To: <20140217091027.GA96287@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/fc9mrxuAQDNmAdFT72ni_zV8Zqo Cc: 'eman mailing list' Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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: Mon, 17 Feb 2014 10:05:58 -0000 Yes, this looks like a good strategy.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, February 17, 2014 11:10 AM > To: Romascanu, Dan (Dan) > Cc: David Prantl; 'Thomas Nadeau'; 'eman mailing list' > Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs >=20 > On Mon, Feb 17, 2014 at 09:00:34AM +0000, Romascanu, Dan (Dan) wrote: > > Hi David, > > > > I have a question about the read-only implementation of draft-ietf-eman= - > battery-mib . There are six writeable objects in the MIB module > batteryAlarmLowCharge, batteryAlarmLowVoltage, > batteryAlarmLowCapacity, batteryAlarmHighCycleCount, > batteryAlarmHighTemperature, batteryAlarmLowTemperature which set > thresholds for notifications. In a read-only implementation how are these > objects set - using CLI instead and then the MIB objects are used to disp= lay > the values set by CLI? Or you do not do notifications at all? > > >=20 > The batteryCompliance seems to allow both options. You are not required t= o > implement batteryAlarmThresholdsGroup. If you choose to do so, you are > not required to implement the objects read-write. Of course, if you suppo= rt > threshold notifications and implement read-only, the parameters must be > set via some other mechanism. >=20 > It may make sense to make the threshold objects conditionally mandatory t= o > implement (at least read-only) if the batteryNotificationsGroup is > implemented so that management applications can see the thresholds > generating the notifications. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Mon Feb 17 04:45:31 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 5F93B1A04DD for ; Mon, 17 Feb 2014 04:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 Vx-L_WWUpegM for ; Mon, 17 Feb 2014 04:45:26 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 574D01A04DB for ; Mon, 17 Feb 2014 04:45:26 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2CDA726F5264; Mon, 17 Feb 2014 07:45:23 -0500 (EST) References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <001801cf2bbc$3b43f870$b1cbe950$@prantl.name> <9904FB1B0159DA42B0B887B7FA8119CA2E41B63A@AZ-FFEXMB04.global.avaya.com> <20140217091027.GA96287@elstar.local> Mime-Version: 1.0 (1.0) In-Reply-To: <20140217091027.GA96287@elstar.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: "Thomas D. Nadeau" Date: Mon, 17 Feb 2014 07:45:23 -0500 To: Juergen Schoenwaelder Archived-At: http://mailarchive.ietf.org/arch/msg/eman/R-vOXAh6Pji1cUinjOVFcKtRCaY Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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: Mon, 17 Feb 2014 12:45:28 -0000 > On Feb 17, 2014, at 4:10 AM, Juergen Schoenwaelder wrote: >=20 >> On Mon, Feb 17, 2014 at 09:00:34AM +0000, Romascanu, Dan (Dan) wrote: >> Hi David, >>=20 >> I have a question about the read-only implementation of draft-ietf-eman-b= attery-mib . There are six writeable objects in the MIB module batteryAlarmL= owCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighC= ycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature which set= thresholds for notifications. In a read-only implementation how are these o= bjects set - using CLI instead and then the MIB objects are used to display t= he values set by CLI? Or you do not do notifications at all? >=20 > The batteryCompliance seems to allow both options. You are not > required to implement batteryAlarmThresholdsGroup. If you choose to do > so, you are not required to implement the objects read-write. Of > course, if you support threshold notifications and implement > read-only, the parameters must be set via some other mechanism. >=20 > It may make sense to make the threshold objects conditionally > mandatory to implement (at least read-only) if the > batteryNotificationsGroup is implemented so that management > applications can see the thresholds generating the notifications. This is generally speaking, the normal mode of operation though rig= ht? Maybe the approach here is to go through and make sure all of the confo= rmance statements conditionally require the read-write objects at least read= -only? Also, it would be good to hear from folks about how many actual rea= d-write implementations exist, as well as read-write deployments. I forgot t= o include that in my original note last week. --Tom >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From nobody Tue Feb 18 09:36:23 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 E7C901A04DE; Tue, 18 Feb 2014 09:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] 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 xGepWZNW2rqr; Tue, 18 Feb 2014 09:36:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C159F1A067C; Tue, 18 Feb 2014 09:36:04 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140218173604.15354.67117.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2014 09:36:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/xyxsF-iiIsPhvjVwRW7BFbyRpMk Cc: eman@ietf.org Subject: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-09.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: Tue, 18 Feb 2014 17:36:20 -0000 --NextPart 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 and Energy Monitoring MIB Author(s) : M. Chandramouli, et al Filename : draft-ietf-eman-energy-monitoring-mib Pages : 68 Date : 2014-02-18 This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-energy-monitoring-mib-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eman-energy-monitoring-mib"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-18093604.I-D@ietf.org> --NextPart-- From nobody Tue Feb 18 12:48:09 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 5F8D41A0214 for ; Tue, 18 Feb 2014 12:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 NQ19ywqlwahg for ; Tue, 18 Feb 2014 12:48:05 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 27FC31A0136 for ; Tue, 18 Feb 2014 12:48:05 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id m12so7908468iga.1 for ; Tue, 18 Feb 2014 12:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O4CxLkyLEQdddCYbDaOlI7WwofHR6oAi1oW3hrxFPxg=; b=lrNW4qA2QRgkosv2qCf54hpaKV5iMXNEnkAjHcCzc77GXa1JkVD3JVgvTAGjiR4WwW LOpkHfjJUNGB7AC9Axh4VWveI7O7LP6ZYNY9QHJjySExgwiHfeK5LI2plUzWklI8nC9O I2vYUR8DVw2UpViuECMTH+VotT6gOZJ8YFOEWeZ+hN5eAQT/jHWjG7GdWlx7z134WnI0 h7SfWKI4BsOvjwm6qgn/fps6Ab7b/37IFhikNAEveTXKmPXr4zuHrd9/K2PGL4KF7jO1 w4Od2d6zzQQOBz29b/sb62ra2cQMvHbrAYkqAx+MQu94MEWG+kQaz5XH3EyYF/bsC5Af Tkdw== X-Received: by 10.50.111.79 with SMTP id ig15mr24026302igb.14.1392756482157; Tue, 18 Feb 2014 12:48:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.1.207 with HTTP; Tue, 18 Feb 2014 12:47:41 -0800 (PST) In-Reply-To: <20140218173604.15354.67117.idtracker@ietfa.amsl.com> References: <20140218173604.15354.67117.idtracker@ietfa.amsl.com> From: Ira McDonald Date: Tue, 18 Feb 2014 15:47:41 -0500 Message-ID: To: Benoit Claise , Ira McDonald Content-Type: multipart/alternative; boundary=089e01294c8c60b05104f2b463f4 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/fjzoD4c18LAH5zBSfR0sXb45uCM Cc: eman mailing list Subject: Re: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-09.txt 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: Tue, 18 Feb 2014 20:48:07 -0000 --089e01294c8c60b05104f2b463f4 Content-Type: text/plain; charset=ISO-8859-1 Hi, I wondered if my comments on this Energy Monitoring MIB were considered in this new version? I sent extensive comments on draft-08 during the WG last call on 27 December 2014. They are in the EMAN mailing list archive at: http://www.ietf.org/mail-archive/web/eman/current/msg02118.html Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Feb 18, 2014 at 12:36 PM, 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 : Power and Energy Monitoring MIB > Author(s) : M. Chandramouli, et al > Filename : draft-ietf-eman-energy-monitoring-mib > Pages : 68 > Date : 2014-02-18 > > This document defines a subset of the Management Information > Base (MIB) for power and energy monitoring of devices. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-eman-energy-monitoring-mib-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --089e01294c8c60b05104f2b463f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I wondered if my comm= ents on this Energy Monitoring MIB were considered in
this new version?<= br>
I sent extensive comments on draft-08 during the WG last call = on 27 December
2014.=A0 They are in the EMAN mailing list archive at:

http://www.i= etf.org/mail-archive/web/eman/current/msg02118.html

Cheers= ,
- Ira


=
Ira McDonald (Musician / Software Architect)
Co-Chair -= TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printin= g WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Tue, Feb 18, 2014 at 12:36 PM, <Internet-Drafts@ietf.org> wrote:
A new Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Energy Management Working Group of the IET= F.

=A0 =A0 Title =A0 =A0 =A0 =A0 : Power and Energy Monitoring MIB
=A0 =A0 Author(s) =A0 =A0 : M. Chandramouli, et al
=A0 =A0 Filename =A0 =A0 =A0: draft-ietf-eman-energy-monitoring-mib
=A0 =A0 Pages =A0 =A0 =A0 =A0 : 68
=A0 =A0 Date =A0 =A0 =A0 =A0 =A0: 2014-02-18

=A0 =A0 =A0 =A0 This document defines a subset of the Management Informatio= n
=A0 =A0 =A0 =A0 Base (MIB) for power and energy monitoring of devices.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/dra= ft-ietf-eman-energy-monitoring-mib-09.txt

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

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


_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman


--089e01294c8c60b05104f2b463f4-- From nobody Tue Feb 18 19:57: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 D4C071A0309 for ; Tue, 18 Feb 2014 19:57:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yXYapMBlEoHC for ; Tue, 18 Feb 2014 19:56:56 -0800 (PST) Received: from server506.appriver.com (server506e.appriver.com [50.56.144.35]) by ietfa.amsl.com (Postfix) with ESMTP id B6B7C1A0253 for ; Tue, 18 Feb 2014 19:56:55 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/18/2014 9:56:51 PM 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-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-45/SG:5 2/18/2014 9:56:28 PM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.9759 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.2012 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/18/2014 9:56:38 PM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: smtp.exg6.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 152347743; Tue, 18 Feb 2014 21:56:51 -0600 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT05-E6.exg6.exghost.com ([10.242.230.112]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 21:56:51 -0600 From: Brad Schoening To: "karagian@cs.utwente.nl" , "eman@ietf.org" Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPLSaem0aRoIn4gkq1hLuS2uNXLg== Date: Wed, 19 Feb 2014 03:56:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.56.144.245] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_CF29914F11CC72bradscoraidcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/4g8lUV6V-H0wB-CunVZiZ-S2J6E Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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, 19 Feb 2014 03:57:02 -0000 --_000_CF29914F11CC72bradscoraidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Georgios, I have made changes to the latest published draft (v9) that should address = you comments 3-7 and 11. For a few of the remaining comment, please see de= tailed responses below: Comment_1 & 2 =96 I wasn't sure what you found unclear here Comment_8 =96 the text immediately above the diagram explains the horizonta= l axis and then the vertical axis. Comment_9 - the text immediately above the diagram already does elaborates= on how the overlapping windows Comment_12 =96 this is a good point, but we felt it would be better to prov= ide examples in the use cases section of the applicability statement. As y= ou observe, use cases could representing both the EnergyMonitoringMIB AND t= he EnergyAwareMIB and this would be best placed in a separate document. Comment_13 =96 compliance with SMIv2 can be assumed since the MIB imports f= rom SNMPv2-SMI, correct? Best Regards, Brad Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: > Date: Tue, 31 Dec 2013 10:17:05 +0000 To: > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 Hi all, Sorry for the delay on providing comments on time for the WGLC of draft-iet= f-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. Here are my comments! Many of the comments that I wanted to send are similar to the ones sent by = Juergen Quittek. Therefore, I will send only the ones that are different! =3D> Regarding: draft-ietf-eman-energy-aware-mib-13: Comment_1: Section 5, page 6 shows the entries/attributes (MIB objects) of= the eaTable and eoRelationTable. In Figure 1 the UML diagram illustrates t= he relationship of the MIB objects in the eatable and eoRelationTable. Howe= ver not all entries (MIB objects) depicted in eaTable and eoRelationTable (= page 6) are shown in the UML diagrams. Please elaborate on this in the text= . Comment_2: In section 5.2, page 20 is mentioned: =93The Energy Object can b= e classified as consuming power or supplying power to other devices or that= Energy Object can perform both of those functions, ..=94. However, in the = formal MIB definition on page 20, eoPowerCategory can get the values: consu= mer (0), producer(1), meter(2), distributor(3) or store(4). From what I can= see no value is provided for the situation that the energy object can perf= orm both functions consumer and producer. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =3D> Regarding draft-ietf-eman-energy-monitoring-mib-08: Comment_1:Section 5: It is not clear what is the relation between the ENERG= Y-OBJECT-MIB MIB module tables, the associated UML diagram given in Figure = 1 and the text other subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.).. Pleas= e make this relation clear. Comment_2: The same holds for the powerAttributeMIB MIB module tables, UML = diagram given in Figure 2 and subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.= ). Comment_3: The description of the powerAttributeMIB MIB module tables on pa= ge 8 is too short. A similar description as the one described for the ENERG= Y-OBJECT-MIB MIB module tables in page 6 could be also provided, Comment_4: Some parts of the UML diagram given in Figure 2 as representing = the relations in the powerAttributeMIB are (probabl) part of the ENERGY-OB= JECT-MIB. These are the Energy ParametersTable and EnergyTable. Comment_5: not all entries (MIB objects) depicted in the ENERGY-OBJECT-MIB = MIB module tables are shown in the UML diagram depicted in Fgure 1.Please e= laborate. Comment_6: the same holds for powerAttributeMIB MIB module tables and the = UML diagram depicted in Figure 2. Comment_7: Maybe the title of Section 5.1 should be: Enetgy Object Identity= , instead of Energy Object Information? Comment_8: The description of the vertical axis used in Figure 3 is not cle= ar to me. Are both horizontal axis and vertical axis representing time. Reg= arding the vertical axis you might want to say that the vertical axis repre= sents the amount of measured power ? Comment_9: The description of Figure 4 is not clear to me. You might includ= e at the right sde of the figure and for each window the term S+L, so (S1+L= , S2+L, S3+L and S4+L). You can then explain that the value of the EoEnergy= Consumed is obtained at these time intervals (Sx+L).. Comment_10: Section 6 is very important and its importance should be emphas= ized more clearly in the Introduction. Comment_11: In Section 6 the term EMAN-MON-MIB is used for the first time. = I considered that it referes to this document. Please emphasize that in the= text. Comment_12: Section 8 provides an example for the implementation of the Ene= rgy Object, including the Energy Object relationships. Is it possible to pr= ovide an example of the IANAEnergyRelationship (in particular regaring aggr= egation) defined in [ENERGY-AWARE-MIB]. Comment_13: Are the MIB objects defined in this draft complying with the me= chanisms defined by SMIv2 [RFC2578, RFC2579, RFC2580? If yes, please emphas= ize this in the document! Best regards, Georgios Karagiannis ________________________________ Van: eman [eman-bounces@ietf.org] namens Thom= as Nadeau [tnadeau@lucidvision.com] Verzonden: maandag 30 december 2013 20:52 To: Juergen Quittek Cc: eman mailing list Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mi= b-08 and draft-ietf-eman-energy-aware-mib-13 The note said 8AM EDT. *) Anyways, send over your comments ASAP. --Tom On Dec 30, 2013:1:46 PM, at 1:46 PM, Juergen Quittek > wrote: > Hi Tom, > I missed the fact that the deadline is already in the morning of today. I= thought I had the full day today for sending them. There are still some co= mments that I planned to send this evening. I will send them asap and hope = they will be OK even if a few hours late. > Thanks, > Juergen > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Montag, 30. Dezember 2013 14:44 >> To: eman mailing list >> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-m= ib- >> 08 and draft-ietf-eman-energy-aware-mib-13 >> >> >> WG, >> >> This concludes the WG LC on the MIBs. We have received just one se= t >> of comments from the WG and one set of comments regarding the OID >> numbering. Would the document editors please address these and republish >> the drafts ASAP so that we can proceed with progressing the drafts? >> >> Cheers and Happy Holidays, >> >> Tom >> >> >>> >>> As agreed at the last WG meeting, with the EMAN Framework >> completing its WG LC the chairs would like to initiate a WG LC on draft-= ietf- >> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >> The WG LC will end on Dec 30 at 8AM EDT. >>> >>> Thank you, >>> >>> Nevil and Tom >>> >>> >>> _______________________________________________ >>> 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 --_000_CF29914F11CC72bradscoraidcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Georgios,

I have made changes to the latest published draft (v9) that should add= ress you comments 3-7 and 11.  For a few of the remaining comment, ple= ase see detailed responses below:

Comment_1 & 2 =96 I wasn't sure what you found unclear here
Comment_8 =96 the text immediately above the diagram explains the hori= zontal axis and then the vertical axis. 
Comment_9 -  the text immediately above the diagram already does = elaborates on how the overlapping windows 
Comment_12 =96 this is a good point, but we felt it would be better to= provide examples in the use cases section of the applicability statement. =  As you observe, use cases could representing both the EnergyMonitorin= gMIB AND the EnergyAwareMIB and this would be best placed in a separate document.
Comment_13 =96 compliance with SMIv2 can be assumed since the MIB impo= rts from SNMPv2-SMI, correct?

Best Regards,

Brad


Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com
Coraid: Redefinin= g Storage


From: <karagian@cs.utwente.nl>
Date: Tue, 31 Dec 2013 10:17:05 = 3;0000
To: <eman@ietf.org>
Subject: Re: [eman] WG Last Call fo= r draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware= -mib-13

.EmailQuote { BORDER-LEFT: #800000 2px solid; PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt }

Hi all,

 

Sorry for the delay on providing comments on time for the WGLC of = draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13.

 

Here are my comments!

Many of the comments that I wanted to send are similar to the ones= sent by Juergen Quittek. Therefore, I will send only the ones that are different!

 

=3D> Regarding: draft-ietf-eman-energy-aware-mib-13:=

 

Comment_1: Section 5, page 6 shows the entries/attributes  (MIB objects) of the eaTable= and eoRelationTable. In Figure 1 the UML diagram illustrates the relations= hip of the MIB objects in the eatable and eoRelationTable. However not all = entries (MIB objects) depicted in eaTable and eoRelationTable (page 6) are shown in the UML diagrams. Please elabora= te on this in the text.

 

Comment_2: In section 5.2, page 20 is mentioned: =93The Energy Obj= ect can be classified as consuming power or supplying power to other devices or that Energy Object can perform both of those fun= ctions, ..=94. However, in the formal MIB definition on page 20, eoPowerCat= egory can get the values: consumer (0), producer(1), meter(2), distributor(= 3) or store(4). From what I can see no value is provided for the situation that the energy object can perform = both functions consumer and producer.

 

 

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

=3D> Regarding draft-ietf-eman-energy-monitoring-mib-08:

 

Comment_1:Section 5: It is not clear what is the relation between = the ENERGY-OBJECT-MIB MIB module tables, the associated UML diagram given in Figure 1 and the text other subsections (5= .1, 5.2, 5.3, 5.4, 5.5 and 5.6.).. Please make this relation clear.

 

Comment_2: The same holds for the powerAttributeMIB MIB module tab= les, UML diagram given in Figure 2 and subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.).

 

Comment_3: The description of the powerAttributeMIB MIB module tab= les on page 8 is too short. A similar description as the one described for the ENERGY-OBJECT-MIB MIB module tables in page 6= could be also provided,

 

Comment_4: Some parts of the UML diagram given in Figure 2 as repr= esenting the relations in the powerAttributeMIB are (probabl)  part of the E= NERGY-OBJECT-MIB. These are the Energy ParametersTable and EnergyTable.

 

Comment_5: not all entries (MIB objects) depicted in the ENERGY-OB= JECT-MIB MIB module tables are shown in the UML diagram depicted in Fgure 1.Please elaborate.=

 

Comment_6: the same holds for powerAttributeMIB MIB module tables  and the UML diagram depicted= in Figure 2.

 

Comment_7: Maybe the title of Section 5.1 should be: Enetgy Object= Identity, instead of Energy Object Information?

 

Comment_8: The description of the vertical axis used in Figure 3 i= s not clear to me. Are both horizontal axis and vertical axis representing time. Regarding the vertical axis you might= want to say that the vertical axis represents the amount of measured power= ?

 

Comment_9: The description of Figure 4 is not clear to me. You mig= ht include at the right sde of the figure and for each window the term S+L, so (S1+L, S2+L, S3+L and S4&= #43;L). You can then explain that the value of the EoEnergyConsumed is obta= ined at these time intervals (Sx+L)..

 

Comment_10: Section 6 is very important and its importance should = be emphasized more clearly in the Introduction.

 

Comment_11: In Section 6 the term EMAN-MON-MIB is used for the fir= st time. I considered that it referes to this document. Please emphasize that in the text.

 

Comment_12: Section 8 provides an example for the implementation o= f the Energy Object, including the Energy Object relationships. Is it possible to provide an example of the IANAEnergyRelat= ionship (in particular regaring aggregation) defined in [ENERGY-AWARE-MIB].=

 

Comment_13: Are the MIB objects defined in this draft complying wi= th the mechanisms defined by SMIv2 [RFC2578, RFC2579, RFC2580? If yes, please emphasize this in the document!

 

Best regards,

Georgios Karagiannis

 

 

 

Van: eman [eman-bounces= @ietf.org] namens Thomas Nadeau [tnadeau@lucidvision.com]
Verzonden: maandag 30 december 2013 20:52
To: Juergen Quittek
Cc: eman mailing list
Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monito= ring-mib-08 and draft-ietf-eman-energy-aware-mib-13


        The note said 8AM EDT. *)

        Anyways, send over your comments= ASAP.

        --Tom


On Dec 30, 2013:1:46 PM, at 1:46 PM, Juergen Quittek <Quittek@neclab.eu> wrote:

> Hi Tom,
> I missed the fact that the deadline is already in the morning of today= . I thought I had the full day today for sending them. There are still some= comments that I planned to send this evening. I will send them asap and ho= pe they will be OK even if a few hours late.
> Thanks,
>    Juergen
>
>> -----Original Message-----
>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau
>> Sent: Montag, 30. Dezember 2013 14:44
>> To: eman mailing list
>> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monito= ring-mib-
>> 08 and draft-ietf-eman-energy-aware-mib-13
>>
>>
>>       WG,
>>
>>       This concludes the WG LC on th= e MIBs. We have received just one set
>> of comments from the WG and one set of comments regarding the OID<= br> >> numbering. Would the document editors please address these and rep= ublish
>> the drafts ASAP so that we can proceed with progressing the drafts= ?
>>
>>       Cheers and Happy Holidays,
>>
>>       Tom
>>
>>
>>>
>>>      As agreed at the last WG meeting= , with the EMAN Framework
>> completing its WG LC the chairs would like to initiate a WG LC on = draft-ietf-
>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib= -13.
>> The WG LC will end on Dec 30 at 8AM EDT.
>>>
>>>      Thank you,
>>>
>>>      Nevil and Tom
>>>
>>>
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>
>

_______________________________________________ eman mailing list eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman --_000_CF29914F11CC72bradscoraidcom_-- From nobody Tue Feb 18 20:29:24 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 A8FCB1A0325 for ; Tue, 18 Feb 2014 20:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BEKAUZ7uuJxp for ; Tue, 18 Feb 2014 20:29:19 -0800 (PST) Received: from server506.appriver.com (server506k.appriver.com [50.56.144.157]) by ietfa.amsl.com (Postfix) with ESMTP id 525491A0129 for ; Tue, 18 Feb 2014 20:29:19 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/18/2014 10:29:14 PM 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-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-14/SG:2 2/18/2014 10:28:16 PM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.972283 Source White X-Signature-Violations: 0-0-0-23357-c X-Note-419: 62.4016 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/18/2014 10:29:07 PM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: smtp.exg6.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 46313026; Tue, 18 Feb 2014 22:29:14 -0600 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT04-E6.exg6.exghost.com ([50.56.144.22]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 22:29:14 -0600 From: Brad Schoening To: Alan Luchuk , "eman@ietf.org" Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPLSsk3UblO5lWEECy3YcSkC9tzw== Date: Wed, 19 Feb 2014 04:29:13 +0000 Message-ID: In-Reply-To: <201312301853.NAA03279@adminfs.snmp.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 x-originating-ip: [50.56.144.245] x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/J3yi_g6MNEsr_7d-I0Mt-rPyMPQ Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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, 19 Feb 2014 04:29:22 -0000 Hi Alan, Thanks for your review of the EnergyMonitoringMib v8 and the many helpful comments. I have fixed or resolved all of the 26+ issues you mention in the latest published draft, v9. Of the two remaining, please see my comments below: #1) In the MIBs, adding eye-catching comments between the tables would ease visually identifying where each MIB table begins. I wasn't sure how to address this. #2) Would it be useful or helpful to have UnitsMultiplier companion objects for the following objects? My feeling is generally, no, because voltage and THD values are not additive and don't have a large range. AC voltage is commonly 120, 240 or 480. THD is a percentage value and also has a fixed range. However, perhaps amperes should be in 0.01 amperes units. I'm not certain, but perhaps this could have a unit multiplier. Finally, when reviewing your comments on eoACPwrAttributesPhaseEntry together with the latest IEC 61850, I realized this could be simplified and have elided the common PhaseEntry table in favor of only Del and Wye subtables. Best Regards, Brad On 12/30/13 1:53 PM, "Alan Luchuk" wrote: >Hello, > >Here are comments about draft-ietf-eman-energy-monitoring-mib-08 and >draft-ietf-eman-energy-aware-mib-13. Due to the holidays, I was unable >to get these sent to the WG E-mail list sooner. > > >Regarding draft-ietf-eman-energy-aware-mib-13: >---------------------------------------------- > >Section 5, Page 6: > > The UML on Page 6 _looks_ incorrect. It _looks_ like the >eoRelationTable > is subordinate to, or a child of, the eoEntry. I'm not sure how the > actual relationship specified in the MIB is _supposed_ to be >represented > in UML. > > >Page 22: > > The eoRelationID in the eoRelationTable is "read-only". In many cases, > I do not see how an energy object can determine the eoRelationID to the > Energy Objects to which it is connected, so I _think_ the eoRelationID > must be configured by the EnMS. I _think_ the eoRelationID should be > a read-write object like the eoRelationship object. > > As an example, consider a manageable, metering power distribution > unit (PDU), I don't see how it can autodiscover and populate the > eoRelationID of the energy objects to which it is connected. The >useful- > ness of the eoRelationID MIB object is reduced if it is only populated > in devices where it can be autodiscovered. > > > >Regarding draft-ietf-eman-energy-monitoring-mib-08: >--------------------------------------------------- > >Section 5, 3rd paragraph, Page 6: > > "entity4CRCompliance. This compliance requires that the > following 3 MIB objects from ENTITY-MIB [RFC6933] > (entPhysicalIndex, entPhysicalName and entPhysicalUUID) MUST be > implemented." > > I think entPhysicalClass should be included in this list. There are > other references to the entity4CRCompliance in this draft that need the > same update. > > >Section 5, Page 7: > > | +-- r-n INTEGER eoMeasurementCaliber(5) > > I think the above should be eoPowerMeasurementCaliber(5). > > | +-- r-n Interger32 eoPowerStateMaxPower(2) > > Change "Interger32" to Integer. > > | +-- r-n Integer32 eoEnergyParametersIntervalMode(5) > > I think the type of "eoEnergyParametersIntervalMode" should be INTEGER. > > >Section 5, Page 8: > > I suggest changing "powerAttributesMIB" to "POWER-ATTRIBUTES-MIB" for > for consistency with previous text that references the >ENERGY-OBJECT-MIB > and POWER-ATTRIBUTES-MIB. > > A quick summary of the function of each of the tables in the POWER- > ATTRIBUTES-MIB, similar to the quick summary of each of the tables in > the ENERGY-OBJECT-MIB (on Page 6) might be helpful and consisent. > > > | +-- r-n Interger32 eoACPwrAttributesAvgVoltage(2) > > | +-- r-n Interger32 > | eoACPwrAttributesTotalActivePower(7) > > Change "Interger32" to Integer. > > In the diagram for the eoACPwrAttributesEntry, after eoACPwrAttributes- > ThdAmpheres, the eoACPwrAttributesThdVoltage object is missing. > > Also, here, and several places in the document, "Ampheres" is >referenced. > Not sure if "Ampheres" is intentional, but "Amperes" might be >preferable. > It might be good to do a case-insensitive search for "ampheres". > > >Section 5, Page 9: > > +-- eoACPwrAttributesDelPhaseEntry(1) > | | [entPhysicalIndex, eoPhaseIndex] > | |=20 > | +-- r-n Integer32 > | | eoACPwrAttributesDelPhaseToNextPhaseVoltage(1) > | +-- r-n Integer32 > | | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage(2) > | +-- r-n Integer32 > eoACPwrAttributesDelThdCurrent(3) > > I think the column numbers 1, 2, and 3, are incorrect. The actual >column=20 > numbers in the MIB are 2, 3, and 4. Perhaps the MIB table should be >fixed=20 > so the column numbers are 1, 2, and 3. > =20 > >Section 5, Page 12. > > At the very top, in the diagram for the eoACPwrAttributesEntry, after > eoACPwrAttributesThdAmpheres, the eoACPwrAttributesThdVoltage object > is missing. > > >Section 5.4, Page 15: > > I suggest changing "powerAttributesMIB" to "POWER-ATTRIBUTES-MIB" for > for consistency with previous text that references the >ENERGY-OBJECT-MIB > and POWER-ATTRIBUTES-MIB. > > >Section 6, Page 20: > > This section references the EMAN-MON-MIB. I think this should be > ENERGY-OBJECT-MIB. > > >Section 9, Page 27: > > This section references the "energyObjectMIBObject". Not sure what >this > is. > > >In the MIBs, adding eye-catching comments between the tables would ease >visually identifying where each MIB table begins. > > >Page 37, "eoPowerOperState" MIB object: > > The second paragraph of the DESCRIPTION clause reads: "Possible values > of eoPowerAdminState...". I think "eoPowerAdminState" should be >changed > to "eoPowerOperState." > > >Page 38, "eoPowerStateTable": > > The text reads: > > This table has an expansion-dependent relationship on the > eoPowerTable, containing rows describing each Power State > for the corresponding Energy Object. For every Energy > Object in the eoPowerTable, there is a corresponding > entry in this table." > > Not sure I correctly understand this table, but should the second >sentence > read something like: "For every Energy Object in the eoPowerTable, >there=20 > is a corresponding set of entries in this table, one entry for each >power=20 > state supported by the Energy Object." > =20 > >Page 38, "eoPowerStateEntry": > > In the DESCRIPTION clause, the state numbers and state names do not >match > any documented enumerations for the IANAPowerStateSet textual >convention. > Should the existing values be replaced with: > > eman(1024), -- indicates EMAN set > emanmechoff(1025), > emansoftoff(1026), > emanhibernate(1027), > emansleep(1028), > emanstandby(1029), > emanready(1030), > emanlowMinus(1031), > emanlow(1032), > emanmediumMinus(1033), > emanmedium(1034), > emanhighMinus(1035), > emanhigh(1036) > > >Page 45, "eoEnergyStored": > > The first sentence of the DESCRIPTION clause reads: > > "This object indicates the resultant of the energy consumed..." > > Perhaps the following text would be clearer: > > "This object indicates the difference of the energy consumed..." > ^^^^^^^^^^ > > >Page 46, "eoEnergyMaxConsumed": > > The DESCRIPTION text reads: > > "This object is the maximum energy ever observed in > eoEnergyConsumed since the monitoring started. This value > is specified in the common billing units of watt-hours > with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) > indicated separately in eoEnergyUnitMultiplier." > > Does this mean that the eoEnergyMaxConsumed value must be retained > across reboots, and thus must be stored in non-volatile memory? > > >Page 48/49/54, where "entity4CRCompliance" is listed: > > I believe the "entPhysicalClass" object must be added to the lists of > MIB objects (entPhysicalIndex, entPhysicalName and entPhysicalUUID). > > >Page 56, "eoACPwrAttributesAvgCurrent": > > It might be niced to expand the DESCRIPTION clause so that it more > precisely specifies the significance of this, perhaps similar to the > DESCRIPTION clause for "eoACPwrAttributesAvgVoltage". > > >Page 56, "eoACPwrAttributesFrequency": > > The UNITS clause does not match the comment after the SYNTAX clause. > > eoACPwrAttributesFrequency OBJECT-TYPE > SYNTAX Integer32 (4500..6500) -- UNITS 0.01 Hertz > UNITS "hertz" > > >Would it be useful or helpful to have UnitsMultiplier companion objects >for=20 >the following objects? > > Page 58, "eoACPwrAttributesThdAmpheres": > Page 60, "eoACPwrAttributesPhaseAvgCurrent": > Page 62, "eoACPwrAttributesDelPhaseToNextPhaseVoltage": > Page 63, "eoACPwrAttributesWyePhaseToNeutralVoltage": > Page 64, "eoACPwrAttributesWyePhaseCurrent": > =20 > >Page 59, "eoACPwrAttributesPhaseEntry": > =20 > Under the DESCRIPTION clause, it might be helpful to add a comment that > indicates the phase-to-phase voltages are in separate tables. > > When I first encountered the "eoACPwrAttributesPhaseEntry", I wondered > about the voltages until I read further in the MIB and found the > eoACPwrAttributesDelPhaseTable and the eoACPwrAttributesWyePhaseTable. > > > >Page 60, "eoACPwrAttributesPhaseActivePower", > "eoACPwrAttributesPhaseReactivePower", > "eoACPwrAttributesPhaseApparentPower": > > Expanding the DESCRIPTION clauses to note these are scaled by the > eoACPwrAttributesPowerUnitMultiplier might be helpful, but the > DESCRIPTION clause for the "eoACPwrAttributesPowerUnitMultiplier" > does note this scaling relationship. > > >Page 61, "eoACPwrAttributesPhaseImpedance": > > Are the UNITS of "volt-amperes" correct? > > > >Page 62/63, "eoACPwrAttributesDelPhaseToNextPhaseVoltage", > "eoACPwrAttributesDelThdPhaseToNextPhaseVoltage", > "eoACPwrAttributesDelThdCurrent": > > The last SID values for these objects are 2, 3, and 4, which distinctly > does NOT match the values shown in the figure on Page 9, which shows > the last SID values as 1, 2, and 3. > > >Page 74, Section 13: > > [EMAN-AWARE-MIB] J. Parello, B. Claise and M. Chandramoili, > "draft-ietf-eman-energy-aware-mib-11 ", work in > progress, November 2013. > > Does it matter, or should this reference draft 13, > draft-ietf-eman-energy-aware-mib-13? > > >Regards, >--Alan > >=20 >-------------------------------------------------------------------------- >---- > 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/ >=20 >-------------------------------------------------------------------------- >---- > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From nobody Tue Feb 18 20:42:57 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 219741A0443 for ; Tue, 18 Feb 2014 20:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 BTgF1PUwJjc8 for ; Tue, 18 Feb 2014 20:42:54 -0800 (PST) Received: from server506.appriver.com (server506e.appriver.com [50.56.144.35]) by ietfa.amsl.com (Postfix) with ESMTP id D7C8B1A0428 for ; Tue, 18 Feb 2014 20:42:53 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/18/2014 10:42:50 PM 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-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-2/SG:2 2/18/2014 10:42:29 PM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.97397 Source White X-Signature-Violations: 0-0-0-5120-c X-Note-419: 15.6006 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 2/18/2014 10:42:40 PM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: smtp.exg6.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 152350514; Tue, 18 Feb 2014 22:42:50 -0600 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT05-E6.exg6.exghost.com ([10.242.230.112]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 22:42:50 -0600 From: Brad Schoening To: Juergen Quittek , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPLS0LlWQHqcIG20qV50Yoti7E3A== Date: Wed, 19 Feb 2014 04:42:49 +0000 Message-ID: In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8688B333E@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.56.144.245] x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-ID: <579A1D2DF4A4F74A8475B60B8580B1C4@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/NxrqISp3iIRvfUNmJWFkCbfqFOU Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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, 19 Feb 2014 04:42:56 -0000 Hi Juergen, Yes, you're correct that the Entity MIB is mandatory. I've corrected that in the updated v9. I also agree that the redundant Module Compliance statements are a little redundant. Not sure if that was worth removing at this point. Best Regards, Brad On 12/30/13 2:33 PM, "Juergen Quittek" wrote: >Dear all, > >Here are my last two comments for this WGLC. Both concerns the >conformance section of the ENERGY-OBJECT-MIB module in >draft-ietf-eman-energy-monitoring-mib-08: > >1. I may have missed a point here: Why is the Entity MIB not mandatory >anymore to implement? It is just two additional objects, since >entPhysicalIndex from this MIB is needed anyway. Particularly, we >considered the UUID provided by this MIB essential for our framework. > >2. Why is the module compliance dependency on the Entity MIB repeated in >the DESCRIPTION clauses of all optional groups within a MODULE-COMPLIANCE >declaration? I think It is fully sufficient to have it stated in the top >DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it make any >sense to repeat it for optional groups? > >Cheers, > Juergen > > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Montag, 16. Dezember 2013 16:56 >> To: eman mailing list >> Subject: [eman] WG Last Call for >>draft-ietf-eman-energy-monitoring-mib-08 >> and draft-ietf-eman-energy-aware-mib-13 >>=20 >>=20 >> As agreed at the last WG meeting, with the EMAN Framework >> completing its WG LC the chairs would like to initiate a WG LC on >>draft-ietf- >> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >> The WG LC will end on Dec 30 at 8AM EDT. >>=20 >> Thank you, >>=20 >> Nevil and Tom >>=20 > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From nobody Wed Feb 19 10:54:57 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 F2E161A014C for ; Wed, 19 Feb 2014 10:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 HrahqIjEZHM9 for ; Wed, 19 Feb 2014 10:54:53 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2E01A00FB for ; Wed, 19 Feb 2014 10:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3881; q=dns/txt; s=iport; t=1392836090; x=1394045690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8lNNrD469aSqp+Nd+4Jyazxg+3c6mOHIFGFgK0Iacyo=; b=C64PdL6czk+CSo2yqLvNOQZJQw/M3fNCofJu7w3oFcGW0AYk553Lw3z5 I++0z8fiRy5ENkqOwReZbEd+WS8xCbfmi0FS9RzfEAjABnyJ9gOp5N+oH Y92ZRcB/Ccls7glL5Y9glB6YU1O3xT7K1bbO1uXRk3n22lTXa/wW75Oo9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANf8BFOtJXG8/2dsb2JhbABWA4MGOFfAAoEbFnSCJQEBAQMBAQEBNzQLBQcCAgIBCBABBAEBAQoUCQcbDAsUCQgCBAENBQiHdQcBDc4UFwSNeBodIRAHBguDE4EUBKpUgy2CKg X-IronPort-AV: E=Sophos;i="4.97,507,1389744000"; d="scan'208";a="305161968" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 19 Feb 2014 18:54:47 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1JIslEj003525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 18:54:47 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.148]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 12:54:47 -0600 From: "John Parello (jparello)" To: "Thomas D. Nadeau" , Juergen Schoenwaelder Thread-Topic: [eman] Read-Only or Read-Write EMAN MIBs Thread-Index: AQHC6u7uCvfdZeN84kmO9TXQlPcsOZrRolswgABpywCAAALDgIAAPA2AgAMkE/A= Date: Wed, 19 Feb 2014 18:54:47 +0000 Message-ID: <9C213D38848B89428F46808B16F6F08601719B99@xmb-aln-x04.cisco.com> References: <88A474D1-677D-4BA0-8399-0429A095AE45@lucidvision.com> <001801cf2bbc$3b43f870$b1cbe950$@prantl.name> <9904FB1B0159DA42B0B887B7FA8119CA2E41B63A@AZ-FFEXMB04.global.avaya.com> <20140217091027.GA96287@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.222.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/itoSSK_VD9QIyi0gn6OWs_uZNqw Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs 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, 19 Feb 2014 18:54:56 -0000 Responding to Tom's request.... """ Also, it would be good to hear from folks about how many actual read-write = implementations exist, as well as read-write deployments. I forgot to inclu= de that in my original note last week. """ Objective Observations: Implementations.... We have a Cisco mib which is close to the mib here out for ~5 years It is both read/write and mgt vendors such as SolarWinds and IBM Tivoli ask= ed for our proprietary mib to have write ability to change the operational = / power state of a device and to add context information when we design rev= iewed it with them. Our Cisco works Prime uses the write values of the mib = for the same use cases. EnMS vendors such as Joulex, CA Ecometer use our pr= oprietary mib with write access again for the same use cases. The PWG (printer working group) which has defined the oper states for print= ers also includes writeable values. Deployments... Too large to count at this point (installed base of solarwinds, Tivoli, Cis= co Prime). Just about every instance of our mgt apps have the RW capability= .=20 IMO : - The compliance should be RO with RW available - The context information if not writeable would be a bit useless if the NM= S could not write to the device. You'd never get deployment context only ma= nufacturer context. - Awkward to detect high power/energy use then not be able to change it HTH Jp -----Original Message----- From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Monday, February 17, 2014 4:45 AM To: Juergen Schoenwaelder Cc: eman mailing list Subject: Re: [eman] Read-Only or Read-Write EMAN MIBs > On Feb 17, 2014, at 4:10 AM, Juergen Schoenwaelder wrote: >=20 >> On Mon, Feb 17, 2014 at 09:00:34AM +0000, Romascanu, Dan (Dan) wrote: >> Hi David, >>=20 >> I have a question about the read-only implementation of draft-ietf-eman-= battery-mib . There are six writeable objects in the MIB module batteryAlar= mLowCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHi= ghCycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature which= set thresholds for notifications. In a read-only implementation how are th= ese objects set - using CLI instead and then the MIB objects are used to di= splay the values set by CLI? Or you do not do notifications at all? >=20 > The batteryCompliance seems to allow both options. You are not=20 > required to implement batteryAlarmThresholdsGroup. If you choose to do=20 > so, you are not required to implement the objects read-write. Of=20 > course, if you support threshold notifications and implement=20 > read-only, the parameters must be set via some other mechanism. >=20 > It may make sense to make the threshold objects conditionally=20 > mandatory to implement (at least read-only) if the=20 > batteryNotificationsGroup is implemented so that management=20 > applications can see the thresholds generating the notifications. This is generally speaking, the normal mode of operation though right? Ma= ybe the approach here is to go through and make sure all of the conformance= statements conditionally require the read-write objects at least read-only= ? Also, it would be good to hear from folks about how many actual read-write= implementations exist, as well as read-write deployments. I forgot to incl= ude that in my original note last week. --Tom >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From nobody Wed Feb 19 12:19:17 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 89F9F1A04F7 for ; Wed, 19 Feb 2014 12:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 TvozSqFHV_vn for ; Wed, 19 Feb 2014 12:19:11 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id B7F401A0401 for ; Wed, 19 Feb 2014 12:19:10 -0800 (PST) Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 20 Feb 2014 05:19:05 +0900 Received: from SMTP3.etri.info ([169.254.4.169]) by SMTP2.etri.info ([169.254.170.108]) with mapi id 14.01.0355.002; Thu, 20 Feb 2014 05:19:06 +0900 From: Sangjin Jeong To: "eman@ietf.org" Thread-Topic: I-D Action: draft-jeong-eman-network-proxy-protocol-02.txt Thread-Index: Ac8tr9ZKvk1M8hfzCE24quBYWdYB9Q== Date: Wed, 19 Feb 2014 20:19:05 +0000 Message-ID: <80C7C745AD85EF4696EC20CCC93011275B6E3563@SMTP3.etri.info> Accept-Language: en-US, ko-KR Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: U2FuZ2ppbiBKZW9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_80C7C745AD85EF4696EC20CCC93011275B6E3563SMTP3etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/bAbqQ3ovsm2nZjDecPTy7XePg2M Subject: [eman] FW: I-D Action: draft-jeong-eman-network-proxy-protocol-02.txt 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, 19 Feb 2014 20:19:16 -0000 --_000_80C7C745AD85EF4696EC20CCC93011275B6E3563SMTP3etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCBhbiB1cGRhdGVkIGRyYWZ0IGRlc2NyaWJp bmcgbmV0d29yayBwcm94eSBwcm90b2NvbCBmb3IgZW5lcmd5IHNhdmluZyBvZiBuZXR3b3JrIG5v ZGVzLCB3aGljaCB3YXMgcHJlc2VudGVkIGFuZCBkaXNjdXNzZWQgaW4gSUVURiBPcmxhbmRvIG1l ZXRpbmcuDQoNClBsZWFzZSBmaW5kIHRoZSBkb2N1bWVudCBhdCB0aGUgZm9sbG93aW5nIGxpbmsg YW5kIHdlIGFyZSBzb2xpY2l0aW5nIGFueSBjb21tZW50Lg0KaHR0cDovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1qZW9uZy1lbWFuLW5ldHdvcmstcHJveHktcHJvdG9jb2wtMDIudHh0DQoNCkJlc3Qg cmVnYXJkcywNClNhbmdqaW4NCg0KPiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t LS0tLS0NCj4gRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPj4NCj4gRGF0ZTogU2F0LCBGZWIgMTUsIDIwMTQgYXQgODozMSBBTQ0K PiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1qZW9uZy1lbWFuLW5ldHdvcmstcHJveHktcHJv dG9jb2wtMDIudHh0DQo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5v dW5jZUBpZXRmLm9yZz4NCj4NCj4NCj4NCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPg0KPg0K PiBUaXRsZSA6IE5ldHdvcmsgUHJveHkgUHJvdG9jb2wNCj4gQXV0aG9yIDogU2FuZ2ppbiBKZW9u Zw0KPiBGaWxlbmFtZSA6IGRyYWZ0LWplb25nLWVtYW4tbmV0d29yay1wcm94eS1wcm90b2NvbC0w Mi50eHQNCj4gUGFnZXMgOiAyMQ0KPiBEYXRlIDogMjAxNC0wMi0xNA0KPg0KPiBBYnN0cmFjdDoN Cj4gSW4gdGhlIGN1cnJlbnQgSW50ZXJuZXQsIGl0IGlzIGltcGxpY2l0bHkgYXNzdW1lZCB0aGF0 IGEgbmV0d29yayBub2RlDQo+IGlzIGFsd2F5cyBhY3RpdmUgc28gdGhhdCBpdCBjYW4gcmVjZWl2 ZSB0aGUgaW5jb21pbmcgcGFja2V0cyBhdCBhbnkNCj4gdGltZS4gQ3VycmVudCBuZXR3b3JraW5n IHNlcnZpY2VzIGFuZCBhcHBsaWNhdGlvbnMgYXJlIGNvbW1vbmx5DQo+IGRlc2lnbmVkIHRvIGJl IGZ1bGx5IGF2YWlsYWJsZSBhdCBhbGwgdGltZXMgd2l0aCBtaW5pbWFsIHJlc3BvbnNlDQo+IHRp bWVzLiBUaGlzIGFzc3VtcHRpb24ga2VlcHMgbmV0d29yayBub2RlcyBmcm9tIGVudGVyaW5nIHNs ZWVwaW5nDQo+IG1vZGUgaW4gb3JkZXIgdG8gcmVkdWNlIGVuZXJneSBjb25zdW1wdGlvbi4gRnVy dGhlciwgZHVyaW5nIHNsZWVwaW5nDQo+IG1vZGUsIG5ldHdvcmsgbm9kZXMgbWF5IG5vdCBpbW1l ZGlhdGVseSByZXNwb25kIHRvIHRoZSBpbmNvbWluZw0KPiBwYWNrZXRzIG9yIGV2ZW4gbG9zZSB0 aGVtLiBJZiBuZXR3b3JrIG5vZGVzIGFyZSBhbGxvd2VkIHRvIGdvIGludG8gYQ0KPiBzbGVlcGlu ZyBtb2RlLCB0aGV5IGNhbiBlZmZlY3RpdmVseSByZWR1Y2UgZW5lcmd5IGNvbnN1bXB0aW9uIGR1 cmluZw0KPiBpZGxlIHBlcmlvZC4gTmV0d29yayBwcm94eSBhbGxvd3MgdG8gZGVsZWdhdGUgbmV0 d29yayBub2RlJ3MgdHJhZmZpYw0KPiBwcm9jZXNzaW5nIHRvIGFuIGV4dGVybmFsIHN5c3RlbSB3 aXRoaW4gYSBuZXR3b3JrLCBzbyB0aGF0IHRoZSBub2Rlcw0KPiBtYWludGFpbiBuZXR3b3JrIHBy ZXNlbmNlIGR1cmluZyB0aGVpciBzbGVlcC4gVGhpcyBkb2N1bWVudA0KPiBkZXNjcmliZXMgY29t bXVuaWNhdGlvbiBtZWNoYW5pc20gYmV0d2VlbiBuZXR3b3JrIG5vZGVzIGFuZCBwcm94eSBpbg0K PiBvcmRlciB0byBhY2NlbGVyYXRlIHRoZSB3aWRlciBkZXBsb3ltZW50IG9mIG5ldHdvcmsgcHJv eHkgbWVjaGFuaXNtLg0KPg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtamVvbmctZW1hbi1uZXR3b3JrLXByb3h5LXByb3RvY29sLw0KPg0KPiBUaGVyZSdzIGFsc28g YSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtamVvbmctZW1hbi1uZXR3b3JrLXByb3h5LXByb3RvY29sLTAyDQo+DQo+IEEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamVvbmctZW1hbi1uZXR3b3JrLXByb3h5 LXByb3RvY29sLTAyDQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJLUQtQW5ub3VuY2Ug bWFpbGluZyBsaXN0DQo+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86SS1ELUFubm91bmNl QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1h bm5vdW5jZQ0KPiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9y Zy9zaGFkb3cuaHRtbA0KPiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVz LnR4dA0K --_000_80C7C745AD85EF4696EC20CCC93011275B6E3563SMTP3etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxkaXYgaWQ9Ik1haWxTaWduU2VudCI+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+DQo8ZGl2IGRpcj0ibHRyIj5IZWxsbyBhbGws PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjwvZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+V2UgaGF2ZSBwdWJsaXNoZWQgYW4gdXBkYXRlZCBkcmFmdCBkZXNj cmliaW5nIG5ldHdvcmsgcHJveHkgcHJvdG9jb2wgZm9yIGVuZXJneSBzYXZpbmcgb2YgbmV0d29y ayBub2Rlcywgd2hpY2ggd2FzIHByZXNlbnRlZCBhbmQgZGlzY3Vzc2VkIGluIElFVEYgT3JsYW5k byBtZWV0aW5nLjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4m bmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPlBsZWFzZSBmaW5kIHRoZSBkb2N1bWVudCBhdCB0 aGUgZm9sbG93aW5nIGxpbmsgYW5kIHdlIGFyZSBzb2xpY2l0aW5nIGFueSBjb21tZW50LjwvZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1q ZW9uZy1lbWFuLW5ldHdvcmstcHJveHktcHJvdG9jb2wtMDIudHh0IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1qZW9uZy1lbWFuLW5ldHdvcmstcHJveHktcHJv dG9jb2wtMDIudHh0PC9hPjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PC9kaXY+DQo8ZGl2IGRpcj0i bHRyIj4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxk aXYgZGlyPSJsdHIiPlNhbmdqaW48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjwvZGl2Pg0KPGRpdiBk aXI9Imx0ciI+Jm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IC0tLS0tLS0tLS0gRm9y d2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCiZndDsgRnJvbTogJmx0OzxhIGhyZWY9Im1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgRGF0ZTogU2F0LCBGZWIgMTUsIDIwMTQg YXQgODozMSBBTTxicj4NCiZndDsgU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtamVvbmctZW1h bi1uZXR3b3JrLXByb3h5LXByb3RvY29sLTAyLnR4dDxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1h aWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGl0 bGUgOiBOZXR3b3JrIFByb3h5IFByb3RvY29sPGJyPg0KJmd0OyBBdXRob3IgOiBTYW5namluIEpl b25nPGJyPg0KJmd0OyBGaWxlbmFtZSA6IGRyYWZ0LWplb25nLWVtYW4tbmV0d29yay1wcm94eS1w cm90b2NvbC0wMi50eHQ8YnI+DQomZ3Q7IFBhZ2VzIDogMjE8YnI+DQomZ3Q7IERhdGUgOiAyMDE0 LTAyLTE0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgSW4gdGhlIGN1 cnJlbnQgSW50ZXJuZXQsIGl0IGlzIGltcGxpY2l0bHkgYXNzdW1lZCB0aGF0IGEgbmV0d29yayBu b2RlPGJyPg0KJmd0OyBpcyBhbHdheXMgYWN0aXZlIHNvIHRoYXQgaXQgY2FuIHJlY2VpdmUgdGhl IGluY29taW5nIHBhY2tldHMgYXQgYW55PGJyPg0KJmd0OyB0aW1lLiBDdXJyZW50IG5ldHdvcmtp bmcgc2VydmljZXMgYW5kIGFwcGxpY2F0aW9ucyBhcmUgY29tbW9ubHk8YnI+DQomZ3Q7IGRlc2ln bmVkIHRvIGJlIGZ1bGx5IGF2YWlsYWJsZSBhdCBhbGwgdGltZXMgd2l0aCBtaW5pbWFsIHJlc3Bv bnNlPGJyPg0KJmd0OyB0aW1lcy4gVGhpcyBhc3N1bXB0aW9uIGtlZXBzIG5ldHdvcmsgbm9kZXMg ZnJvbSBlbnRlcmluZyBzbGVlcGluZzxicj4NCiZndDsgbW9kZSBpbiBvcmRlciB0byByZWR1Y2Ug ZW5lcmd5IGNvbnN1bXB0aW9uLiBGdXJ0aGVyLCBkdXJpbmcgc2xlZXBpbmc8YnI+DQomZ3Q7IG1v ZGUsIG5ldHdvcmsgbm9kZXMgbWF5IG5vdCBpbW1lZGlhdGVseSByZXNwb25kIHRvIHRoZSBpbmNv bWluZzxicj4NCiZndDsgcGFja2V0cyBvciBldmVuIGxvc2UgdGhlbS4gSWYgbmV0d29yayBub2Rl cyBhcmUgYWxsb3dlZCB0byBnbyBpbnRvIGE8YnI+DQomZ3Q7IHNsZWVwaW5nIG1vZGUsIHRoZXkg Y2FuIGVmZmVjdGl2ZWx5IHJlZHVjZSBlbmVyZ3kgY29uc3VtcHRpb24gZHVyaW5nPGJyPg0KJmd0 OyBpZGxlIHBlcmlvZC4gTmV0d29yayBwcm94eSBhbGxvd3MgdG8gZGVsZWdhdGUgbmV0d29yayBu b2RlJ3MgdHJhZmZpYzxicj4NCiZndDsgcHJvY2Vzc2luZyB0byBhbiBleHRlcm5hbCBzeXN0ZW0g d2l0aGluIGEgbmV0d29yaywgc28gdGhhdCB0aGUgbm9kZXM8YnI+DQomZ3Q7IG1haW50YWluIG5l dHdvcmsgcHJlc2VuY2UgZHVyaW5nIHRoZWlyIHNsZWVwLiBUaGlzIGRvY3VtZW50PGJyPg0KJmd0 OyBkZXNjcmliZXMgY29tbXVuaWNhdGlvbiBtZWNoYW5pc20gYmV0d2VlbiBuZXR3b3JrIG5vZGVz IGFuZCBwcm94eSBpbjxicj4NCiZndDsgb3JkZXIgdG8gYWNjZWxlcmF0ZSB0aGUgd2lkZXIgZGVw bG95bWVudCBvZiBuZXR3b3JrIHByb3h5IG1lY2hhbmlzbS48YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWplb25nLWVtYW4tbmV0d29yay1wcm94eS1wcm90b2NvbC8iIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWplb25nLWVtYW4tbmV0 d29yay1wcm94eS1wcm90b2NvbC88L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamVvbmctZW1hbi1uZXR3b3JrLXByb3h5LXBy b3RvY29sLTAyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1qZW9uZy1lbWFuLW5ldHdvcmstcHJveHktcHJvdG9jb2wtMDI8L2E+PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWplb25nLWVtYW4tbmV0d29yay1wcm94eS1wcm90b2NvbC0wMiIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamVvbmctZW1hbi1uZXR3 b3JrLXByb3h5LXByb3RvY29sLTAyPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQomZ3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88 L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyA8YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+SS1ELUFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTwvYT48 YnI+DQomZ3Q7IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiA8YSBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sPC9hPjxicj4NCiZndDsgb3IgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYu b3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvYT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_80C7C745AD85EF4696EC20CCC93011275B6E3563SMTP3etriinfo_-- From nobody Thu Feb 20 09:51:56 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 707941A0218 for ; Thu, 20 Feb 2014 09:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 xKElfdKoWyJJ for ; Thu, 20 Feb 2014 09:51:49 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 81DCB1A0053 for ; Thu, 20 Feb 2014 09:51:48 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uy17so12164934igb.4 for ; Thu, 20 Feb 2014 09:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=GJ4Xb51u0Xkoil8cx5O5asnuqST+C60WGoMJwoXlLi0=; b=IbMezjLk4toRfDnJqopW2J9x6KvhyuOEDMrM8PcaLwd470AUJWxCxAQTN9ePft0ros 2NvM+ou46cDocnFz6YEuN20plsUp4YvGkfpuv3y5Nm+BHX9AGoy/kqggCIFT+k1Wvytl fFt2RrZs2g4Hmn0fSx3N1QFaKwPydda4DdWVjmvT9LMTMxvmRgkCFzo2Hd6yeeVx3yb2 VhegJlCQhGTtyM6nQDeMxfAc2lO17q10rlyKpr3wZtr4E4gQgsdheGMIMxan0RqP9oBF W6JwFAY3GScbewxExnI+Vkr8DW8Fyey9Gw2VlOJOiv+QjTWTkDncv6GAeB+B51uckasS lzWg== X-Received: by 10.50.50.241 with SMTP id f17mr7801186igo.23.1392918704613; Thu, 20 Feb 2014 09:51:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.1.207 with HTTP; Thu, 20 Feb 2014 09:51:23 -0800 (PST) In-Reply-To: References: From: Ira McDonald Date: Thu, 20 Feb 2014 12:51:23 -0500 Message-ID: To: Brad Schoening , Ira McDonald , eman mailing list Content-Type: multipart/alternative; boundary=047d7bd6bdfc96eea204f2da2814 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/qFxNiYjF7YenvBVbD1n7wDkyfC8 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 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, 20 Feb 2014 17:51:53 -0000 --047d7bd6bdfc96eea204f2da2814 Content-Type: text/plain; charset=ISO-8859-1 Hi Brad, Thanks for considering my comments on Energy Monitoring MIB. I've replied inline to your remaining questions below. Cheers, - Ira On Tue, Feb 18, 2014 at 8:49 PM, Brad Schoening wrote: > Hi Ira, > > Thanks so much for your detailed and very specific feedback on the > Energy Monitoring MIB. It was a huge help. I have corrected or changed 65 > of the 70 issues you raised. For the few remainders, my comments are below > > #52 - this is explained on page 16 (sec 5.7) and mentions "The choices > of the three different modes of collection are based on IEC standard > 61850-7-4" as a reference for further details. > OK > > #54 - for a 15 minute measurement interval, unity, in units of seconds > seconds seemed the only appropriate default > OK > > #55 - we felt offline information would be stale and could be deleted > OK > > #60 - the issue in question here wasn't clear to me > (60) Page 49 (ambiguity) > - please explain why only 'read-create' and 'read-only' are > described, but 'read-write' is not described (useful for > statically allocated tables, using 'notInService' for a toggle) > You define read-create compliance in "energyObjectMIBFullCompliance" and read-only compliance in "energyObjectMIBReadOnlyCompliance". In my experience, tables w/ RowStatus can be implemented more easily (sometimes) with pre-allocated static rows that can simply be turned on and off by read-write access (but not created or destroyed - the tricky bits to get right). Given strong pushback against read-write access, I withdraw my comment. > #69 - I'm not sure about this issue and could use more detail > (69) Page 72 (unsafe allocation of new MIB objects) > - please explain why Expert Review (rather than a new RFC) > is allowed for defining new MIB objects - seems inherently unsafe > (in section 13 IANA Considerations) > Defining new standards-track MIB objects (not just values) by Expert Review (rather than a new RFC) has two drawbacks: (1) Subverts the spirit of standards track data models, I think. (2) Results in surprising, unexpected objects retrieved by SNMP Managers using a MIB walk approach - which can yield confusing error messages in logs and presented to operators. But my comment is obsolete, because the questionable text has been removed in the current draft-09 version. However, shouldn't IANA Considerations address the use of Expert Review (for example) to define new values of existing MIB objects? > > From: Ira McDonald > Date: Mon, 30 Dec 2013 09:58:36 -0500 > To: Thomas Nadeau , Ira McDonald < > blueroofmusic@gmail.com> > Cc: eman mailing list > > Subject: Re: [eman] WG Last Call for > draft-ietf-eman-energy-monitoring-mib-08 and > draft-ietf-eman-energy-aware-mib-13 > > Hi Thomas, > > Ahem - I did send the attached extensive comments on the Energy > Monitoring MIB > three days ago to the EMAN mailing list. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Mon, Dec 30, 2013 at 8:43 AM, Thomas Nadeau wrote: > >> >> WG, >> >> This concludes the WG LC on the MIBs. We have received just one >> set of comments from the WG and one set of comments regarding the OID >> numbering. Would the document editors please address these and republish >> the drafts ASAP so that we can proceed with progressing the drafts? >> >> Cheers and Happy Holidays, >> >> Tom >> >> >> > >> > As agreed at the last WG meeting, with the EMAN Framework >> completing its WG LC the chairs would like to initiate a WG LC on >> draft-ietf-eman-energy-monitoring-mib-08 and >> draft-ietf-eman-energy-aware-mib-13. The WG LC will end on Dec 30 at 8AM >> EDT. >> > >> > Thank you, >> > >> > Nevil and Tom >> > >> > >> > _______________________________________________ >> > 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 >> >> > _______________________________________________ eman mailing list > eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman > --047d7bd6bdfc96eea204f2da2814 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Brad,

Thanks for consi= dering my comments on Energy Monitoring MIB.

I've replied = inline to your remaining questions below.

Cheers,
- I= ra



On Tue, Feb 18, 2014 at 8:49 PM, Brad Schoening <= brads@coraid.com&= gt; wrote:
Hi Ira,

Thanks so much for your detailed and very spe= cific feedback on the Energy Monitoring MIB.  It was a huge help. &nbs= p;I have corrected or changed 65 of the 70 issues you raised.  For the= few remainders, my comments are below

#52 – this is explained on page 16 (sec= 5.7) and mentions "The choices of= the three different modes of collection are based on IEC standard 61850-7-= 4" as a reference for further details.  

<ira> OK </ira>

#54 – for a 15 minute measurement inter= val, unity, in units of seconds seconds seemed the only appropriate default=

<ira> OK </ira= > 

#55 – we felt offline information would= be stale and could be deleted

<ira> OK </ira>

#60 – the issue in question here wasn't clear to me
(60) = Page 49 (ambiguity)
- please explain why only 'read-create' and = 'read-only' are
described, but 'read-write' is not descr= ibed (useful for
statically allocated tables, using 'notInService' for a toggle)
=
 
<ira>= ;
You define read-create compliance in "energyObjectMIBF= ullCompliance"
and read-only compliance in "energyObjectMIBReadOnlyComplia= nce".
In my experience, tables w/ RowStatus can be imple= mented more easily
(sometimes) with pre-allocated static rows= that can simply be turned on
and off by read-write access (but not created or destroyed - the= tricky bits
to get right).

Given strong pu= shback against read-write access, I withdraw my comment.
</ira>


#69 – I'm not sure about this issue= and could use more detail 
(69) Page 72 (unsafe allocation of new MIB ob= jects)
- please explain why Expert Review (rather than a new RFC)
is = allowed for defining new MIB objects - seems inherently unsafe
(in secti= on 13 IANA Considerations)

<ira><= br>
Defining new standards-track MIB objects (not just values) by= Expert Review
(rather than a new RFC) has two drawbacks:

(1) Subverts the spirit of standards track data models, I think.
(2) Results in surprising, unexpected objects retrieved by SNMP Man= agers
using a MIB walk approach - which can yield confusing e= rror messages in
logs and presented to operators.

But my commen= t is obsolete, because the questionable text has been
removed in the cur= rent draft-09 version.

However, shouldn't IANA Consid= erations address the use of Expert Review
(for example) to define new values of existing MIB objects?
<= /div>
</ira>

From: Ira McDonald <blueroofmusic@gmail.com>
Date: Mon, 30 Dec 2013 09:58:36 -05= 00
To: Thomas Nadeau <tnadeau@lucidvision.com= >, Ira McDonald <blueroofmusic@gmail.com>
Cc: eman mailing list <eman@ietf.org>

Subject: Re: [eman] WG Last Call fo= r draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware= -mib-13

Hi Thomas,

Ahem - I did send the attached extensive comments on the Energy Monitoring = MIB
three days ago to the EMAN mailing list.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic=
http://sites.google.com/site/highnorthinc mailto: bluero= ofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094<= br> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Mon, Dec 30, 2013 at 8:43 AM, Thomas Nadeau <= span dir=3D"ltr"> <tnadeau@lu= cidvision.com> wrote:

        WG,

        This concludes the WG LC on the MIBs. We have r= eceived just one set of comments from the WG and one set of comments regard= ing the OID numbering. Would the document editors please address these and = republish the drafts ASAP so that we can proceed with progressing the drafts?

        Cheers and Happy Holidays,

        Tom


>
>       As agreed at the last WG meeting, with the EMAN F= ramework completing its WG LC the chairs would like to initiate a WG LC on = draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-m= ib-13.  The WG LC will end on Dec 30 at 8AM EDT.
>
>       Thank you,
>
>       Nevil and Tom
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman


_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman


_______________________________________________ eman mailing list eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman

--047d7bd6bdfc96eea204f2da2814-- From nobody Sun Feb 23 15:26:44 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 64FDE1A0768 for ; Sun, 23 Feb 2014 15:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 oATSoZjdLNzE for ; Sun, 23 Feb 2014 15:26:41 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B7A511A01CF for ; Sun, 23 Feb 2014 15:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1393198001; x=1424734001; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=6XvWGryfCtblmFkx6YKz36xDk+Q7C5q9ia1wqkA7qNY=; b=DlhRdJYJPXMp4zEmb6FgdlaCBxkGcTg7SJMpDFx1VHMEQ3HtrdTAOA46 DsNTzP4sDgWKIRVvMf6kA/t/GS5L14AaPx6+Jk2lcD1mKxp1jq+z4qiA/ azG9q5zGOuJcO/thmWSmUpFDW/XYNehdRkXgdB7r+aVZZHSELe4/6YbME 4=; X-IronPort-AV: E=Sophos;i="4.97,530,1389697200"; d="scan'208";a="235514115" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 24 Feb 2014 12:26:37 +1300 Message-ID: <530A83AC.5060103@auckland.ac.nz> Date: Mon, 24 Feb 2014 12:26:36 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "eman@ietf.org" References: <53013EF3.1000407@auckland.ac.nz> In-Reply-To: <53013EF3.1000407@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/eman/pEfG0ub4Vryj91uzcltmXH_EgJs Subject: Re: [eman] Agenda for EMAN meeting at IETF-89, London 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: Sun, 23 Feb 2014 23:26:43 -0000 Hi all: I've posted an amended agenda for our London meeting, you can see it by clicking on 'Energy Management' at the right-hand side of the meeting agenda web page. Once again, draft authors, please let me know who will be presenting, and please send me you slides by Saturday, 1 March! Cheers, Nevil On 17/02/14 11:42 AM, Nevil Brownlee wrote: > > Hi all: > > I've put the EMAN agenda online, you can see it by clicking on > 'Energy Management' at the right-hand side of the meeting agenda > web page. > > Draft authors: please let me know who will be presenting your draft > sometime soon so that I can update the agenda. Also, please note > that our session is on Monday afternoon - I'll need your slides > one or two days before that so that I can put them up on the > Meeting Materials page. > > Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Sun Feb 23 15:47: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 60B0D1A076C for ; Sun, 23 Feb 2014 15:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 AwloSlg13njP for ; Sun, 23 Feb 2014 15:46:57 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 85BC91A0768 for ; Sun, 23 Feb 2014 15:46:57 -0800 (PST) Received: from localhost ([127.0.0.1]:58026 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WHikm-0002Ka-LU; Mon, 24 Feb 2014 00:46:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-applicability-statement@tools.ietf.org, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Sun, 23 Feb 2014 23:46:36 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/38#comment:1 Message-ID: <078.1ca6364f1963b2850d77b26995c7998c@trac.tools.ietf.org> References: <063.6e606156e19b182c36ac2e30de665ef9@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <063.6e606156e19b182c36ac2e30de665ef9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-applicability-statement@tools.ietf.org, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bnordman@lbl.gov, brad.schoening@verizon.net, moulchan@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/eman/iVnBAy79LLirR13PuI6ShJgbK68 Cc: eman@ietf.org Subject: Re: [eman] #38: Reference EnMS definition instead of redefining 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, 23 Feb 2014 23:47:01 -0000 #38: Reference EnMS definition instead of redefining Changes (by n.brownlee@auckland.ac.nz): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-eman- b.hedstrom@cablelabs.com | applicability- Type: defect | statement@tools.ietf.org Priority: major | Status: closed Component: applicability-statement | Milestone: Severity: - | Version: 2.0 Keywords: | Resolution: fixed -------------------------------------+------------------------------------- Ticket URL: eman From nobody Sun Feb 23 15:55:11 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 9F0C51A0773 for ; Sun, 23 Feb 2014 15:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 EsDtV3CxtB5F for ; Sun, 23 Feb 2014 15:55:07 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8509B1A0774 for ; Sun, 23 Feb 2014 15:55:06 -0800 (PST) Received: from localhost ([127.0.0.1]:58248 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WHisp-0005IZ-ES; Mon, 24 Feb 2014 00:54:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-applicability-statement@tools.ietf.org, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Sun, 23 Feb 2014 23:54:55 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/38#comment:2 Message-ID: <078.b24671987d88ae25dfb4cb163cf4a249@trac.tools.ietf.org> References: <063.6e606156e19b182c36ac2e30de665ef9@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <063.6e606156e19b182c36ac2e30de665ef9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-applicability-statement@tools.ietf.org, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bnordman@lbl.gov, brad.schoening@verizon.net, moulchan@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/eman/zozcTosbOMsW1uq_ChAUP1VcRKE Cc: eman@ietf.org Subject: Re: [eman] #38: Reference EnMS definition instead of redefining 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, 23 Feb 2014 23:55:08 -0000 #38: Reference EnMS definition instead of redefining Changes (by n.brownlee@auckland.ac.nz): * status: closed => reopened * resolution: fixed => -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-eman- b.hedstrom@cablelabs.com | applicability- Type: defect | statement@tools.ietf.org Priority: major | Status: reopened Component: applicability-statement | Milestone: Severity: - | Version: 2.0 Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: eman From nobody Thu Feb 27 02:06:30 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 623CC1A0806; Thu, 27 Feb 2014 02:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 dk2oNI3xcIGz; Thu, 27 Feb 2014 02:06:26 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 693341A07EF; Thu, 27 Feb 2014 02:06:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B9B88106E5C; Thu, 27 Feb 2014 11:06:24 +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 vjNbFzu6LezB; Thu, 27 Feb 2014 11:06:24 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 99F3F106E84; Thu, 27 Feb 2014 11:06:04 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 27 Feb 2014 11:06:04 +0100 From: Juergen Quittek To: Thomas Nadeau , "draft-ietf-eman-battery-mib@tools.ietf.org" Thread-Topic: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11 Thread-Index: AQHPGUrAPWHfU4CFBUe1IOKiozRfY5rHwzYA Date: Thu, 27 Feb 2014 10:06:04 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6D34F@PALLENE.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eman/vN-u3kESSD4HoK87wIp3Fn3vmcg Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11 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, 27 Feb 2014 10:06:28 -0000 Dear Tom, Thank you very much for your review.=20 Please see replies in line. This email addresses all of your issues except for the last one which I will reply to in a separate message. Cheers, Juergen > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Freitag, 24. Januar 2014 22:24 > To: draft-ietf-eman-battery-mib@tools.ietf.org > Cc: MIB Doctors (E-mail); eman mailing list > Subject: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11 >=20 >=20 >=20 > I reviewed this draft as part of the MIB Doctor review on Friday, > January 24, 2014. > In general the MIB is in good shape. I have some questions/comments inlin= e > begin with TOM: >=20 > General Comments on the draft: >=20 > 1) My run of id-nits produced no errors and a few warnings that can be > ignored. >=20 > 2) In general, please go through the MIB modules and verify that the > Integer32 values are indeed ok to be negative values or change them to > Unsigned. For example, there are many instances where you used Integer32 > for things like watts or amps where negative values do not make sense, to > me at least. We use Integer32 for Current and temperatures. For temperature we do not use Kelvin, but degree Celsius as units which may have negative values. For current the DESCRIPTION clause explains that positive values are for chargi= ng current and negative values are for discharging current. > [snip] > -------------------------------------------------------------------- > -- 1.1. Battery Table > -------------------------------------------------------------------- > batteryTable OBJECT-TYPE > SYNTAX SEQUENCE OF BatteryEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table provides information on batteries. It contains > one conceptual row per battery. >=20 > TOM: Is this a set of batteries per managed device? Yes. For example, the notebook I am writing this email on has two batteries= . Proposal: OLD "This table provides information on batteries. It contains=20 one conceptual row per battery. =20 NEW "This table provides information on batteries. It contains=20 one conceptual row per battery in a managed entity =20 > =20 [snip] >=20 > batteryTemperature OBJECT-TYPE > SYNTAX Integer32 > UNITS "deci-degrees Celsius" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The ambient temperature at or near the battery. >=20 > TOM: Is there some spec that defines what "near" means? No, there is not. Actual implementations vary significantly. Some sensors a= re directly attached to or even inside the battery, some are a few centimet= ers away from the battery, but (hopefully) in the flow of heated air that p= assed the battery for cooling. Even for sensors inside the battery, there a= re problems. Sometimes single cells in a multi-cell battery become very hot= . Then it depends on the location of the sensor (close to the particular ce= ll or rather far away) if this is observable from outside. >=20 [snip] >=20 > batteryAlarmHighCycleCount OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object provides the upper threshold value for object > batteryChargingCycleCount. If the value of object > batteryChargingCycleCount rises above this threshold, > a battery aging alarm will be raised. The alarm procedure > may include generating a batteryAgingNotification. >=20 > A value of 0 indicates that no alarm will be raised for any > value of object batteryChargingCycleCount." >=20 > TOM: Is there any sort of holding time period over which an alarm should= be > not emitted? I can imagine a case where a battery is charged, discharged, > etc... and just goes above and below this threshold causing a lot of > notifications to be emitted. Another option would be to add variable that > defines X numebr of notifications per time period. Yes, there is. We have specified this in the DESCRIPTION clauses of=20 Some NOTIFICATION-TYPEs but apparently not for all where this would Be desirable. Please see a separate email on this issue. For the cycle count alarm above we do not see a need for this, because=20 The cycle count is monotonically increasing. =20 >=20 [snip] >=20 > batteryTemperatureNotification NOTIFICATION-TYPE > OBJECTS { > batteryTemperature, > batteryCellIdentifier > } > STATUS current > DESCRIPTION > "This notification can be generated when the measured > temperature (batteryTemperature) rises above the threshold > defined by object batteryAlarmHighTemperature or falls > below the threshold defined by object > batteryAlarmLowTemperature. >=20 > If the low or high temperature has been detected for a > single cell or a set of cells of the battery and not for the > entire battery, then object batteryCellIdentifier should be > set to a value that identifies the cell or set of cells. > Otherwise, the value of object batteryCellIdentifier should > be set to the empty string when this notification is > generated." > ::=3D { batteryNotifications 4 } >=20 > TOM: The same comment about rate limiting as above. I can see when a > battery is failing this value could float just about and below this value= causing > numerious notifications to be issued. Have you considered such cases? Please see separate email. Thanks, Juergen From nobody Thu Feb 27 03:44:27 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 6A6CF1A012B; Thu, 27 Feb 2014 03:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 ax4kBlLpJbl5; Thu, 27 Feb 2014 03:44:23 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7FF1A018F; Thu, 27 Feb 2014 03:44:23 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5402F270A13F; Thu, 27 Feb 2014 06:44:21 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_976B61A0-E6C8-4995-A714-6B99675923F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6D34F@PALLENE.office.hd> Date: Thu, 27 Feb 2014 06:44:19 -0500 Message-Id: <5FB8FBDF-C7AD-42F9-9E7C-60813DDC5149@lucidvision.com> References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6D34F@PALLENE.office.hd> To: Juergen Quittek X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/eman/TEeTrOWLOZs97wFsuMPs48r-vWw Cc: "MIB Doctors \(E-mail\)" , eman mailing list , "draft-ietf-eman-battery-mib@tools.ietf.org" Subject: Re: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11 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, 27 Feb 2014 11:44:25 -0000 --Apple-Mail=_976B61A0-E6C8-4995-A714-6B99675923F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 27, 2014:5:06 AM, at 5:06 AM, Juergen Quittek = wrote: > Dear Tom, >=20 > Thank you very much for your review.=20 > Please see replies in line. This email addresses all of your issues > except for the last one which I will reply to in a separate message. > Cheers, > Juergen >=20 >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Freitag, 24. Januar 2014 22:24 >> To: draft-ietf-eman-battery-mib@tools.ietf.org >> Cc: MIB Doctors (E-mail); eman mailing list >> Subject: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11 >>=20 >>=20 >>=20 >> I reviewed this draft as part of the MIB Doctor review on = Friday, >> January 24, 2014. >> In general the MIB is in good shape. I have some questions/comments = inline >> begin with TOM: >>=20 >> General Comments on the draft: >>=20 >> 1) My run of id-nits produced no errors and a few warnings that can = be >> ignored. >>=20 >> 2) In general, please go through the MIB modules and verify that = the >> Integer32 values are indeed ok to be negative values or change them = to >> Unsigned. For example, there are many instances where you used = Integer32 >> for things like watts or amps where negative values do not make = sense, to >> me at least. >=20 > We use Integer32 for Current and temperatures. For temperature we do = not > use Kelvin, but degree Celsius as units which may have negative = values. For > current the DESCRIPTION clause explains that positive values are for = charging > current and negative values are for discharging current. TOM: OK. Just ensure that the descriptions are clear of these boundary = conditions. >=20 >>=20 > [snip] >> = -------------------------------------------------------------------- >> -- 1.1. Battery Table >> = -------------------------------------------------------------------- >> batteryTable OBJECT-TYPE >> SYNTAX SEQUENCE OF BatteryEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "This table provides information on batteries. It contains >> one conceptual row per battery. >>=20 >> TOM: Is this a set of batteries per managed device? >=20 > Yes. For example, the notebook I am writing this email on has two = batteries. >=20 > Proposal: > OLD > "This table provides information on batteries. It contains=20 > one conceptual row per battery. =20 > NEW > "This table provides information on batteries. It contains=20 > one conceptual row per battery in a managed entity TOM: Cool. >=20 >>=20 > [snip] >>=20 >> batteryTemperature OBJECT-TYPE >> SYNTAX Integer32 >> UNITS "deci-degrees Celsius" >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The ambient temperature at or near the battery. >>=20 >> TOM: Is there some spec that defines what "near" means? >=20 > No, there is not. Actual implementations vary significantly. Some = sensors are directly attached to or even inside the battery, some are a = few centimeters away from the battery, but (hopefully) in the flow of = heated air that passed the battery for cooling. Even for sensors inside = the battery, there are problems. Sometimes single cells in a multi-cell = battery become very hot. Then it depends on the location of the sensor = (close to the particular cell or rather far away) if this is observable = from outside. TOM: Maybe change "near" to "within close proximity" ? >>=20 > [snip] >>=20 >> batteryAlarmHighCycleCount OBJECT-TYPE >> SYNTAX Unsigned32 >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "This object provides the upper threshold value for object >> batteryChargingCycleCount. If the value of object >> batteryChargingCycleCount rises above this threshold, >> a battery aging alarm will be raised. The alarm procedure >> may include generating a batteryAgingNotification. >>=20 >> A value of 0 indicates that no alarm will be raised for any >> value of object batteryChargingCycleCount." >>=20 >> TOM: Is there any sort of holding time period over which an alarm = should be >> not emitted? I can imagine a case where a battery is charged, = discharged, >> etc... and just goes above and below this threshold causing a lot of >> notifications to be emitted. Another option would be to add variable = that >> defines X numebr of notifications per time period. >=20 > Yes, there is. We have specified this in the DESCRIPTION clauses of=20 > Some NOTIFICATION-TYPEs but apparently not for all where this would > Be desirable. Please see a separate email on this issue. TOM: Indeed. Can you please ensure that each one has this? Otherwise we = could have interop issues.=20 > For the cycle count alarm above we do not see a need for this, because=20= > The cycle count is monotonically increasing. TOM: Again, its good to explicitly put that into the description so that = interop of implementations can be made easier. >=20 >>=20 > [snip] >>=20 >> batteryTemperatureNotification NOTIFICATION-TYPE >> OBJECTS { >> batteryTemperature, >> batteryCellIdentifier >> } >> STATUS current >> DESCRIPTION >> "This notification can be generated when the measured >> temperature (batteryTemperature) rises above the threshold >> defined by object batteryAlarmHighTemperature or falls >> below the threshold defined by object >> batteryAlarmLowTemperature. >>=20 >> If the low or high temperature has been detected for a >> single cell or a set of cells of the battery and not for = the >> entire battery, then object batteryCellIdentifier should be >> set to a value that identifies the cell or set of cells. >> Otherwise, the value of object batteryCellIdentifier should >> be set to the empty string when this notification is >> generated." >> ::=3D { batteryNotifications 4 } >>=20 >> TOM: The same comment about rate limiting as above. I can see when a >> battery is failing this value could float just about and below this = value causing >> numerious notifications to be issued. Have you considered such cases? >=20 > Please see separate email. >=20 > Thanks, > Juergen >=20 --Apple-Mail=_976B61A0-E6C8-4995-A714-6B99675923F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTDyUUAAoJEPcO+I7eiUJZETUP/3x2csoe9HEieGh86sB1q3ry ROPtNrLLzHzzOudV5sZl2BW8bCA0iGKQnzOqC7MgPKqXSQaOMIIMYPPvXpnEPbJD qgdXjHjvkop8/uOvvBIdEm+g0XNQSPC4I85YS/i35N/Jflvn/pSxt7ElEcQei3Sp qcQm10SOo00/bk2npY6OSzBNHDoArmr5cZiY+/nyAG4rgW3MnmWhXXtouILERSTz PkYkbpsBoeX/GCf7dAagUGs/f0wTRQx01dbWlQaIgEMbwIifwGK8KJMuKkPiVUqK Q6Y11lB+CkGGZrjbPBnzxy/A+8snjfIWUfcjD21986vUU8PKAVa29/ApT/fbZbCu gfcjYUe55VxUr37OxS+sWwaTeXpNQJgcWRmr9wr8FtYqguTB8fi5HzLmi6nde1/5 hldwfnElOOy1CuVfQJL1RCf6k5SKQCX5x//9V+ZGvD80bDPQummi2eXcWCANgh6K ZK2m2OY48uMO+T7l9MDHN3pDTiMdyGcP/A5cuHJAJr3w+nvvrvsyMvlnp9xZbH65 m8ASxXVfnaTDvSW+SOp26jNLHT6VwGQVSvyZqjciQBhoc213hLjBLpSqzztuKsC3 NC2n4KV6Od8gqHo+Lcfcm8+hN4C20Zf/58za1sw1Kz64wI62x2BEiM2BDCYgFL48 zan1zc4aYYU1xuv6tJUB =waIq -----END PGP SIGNATURE----- --Apple-Mail=_976B61A0-E6C8-4995-A714-6B99675923F3--