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

From: Brad Schoening <[email-masked]>
Date: Wed, 19 Feb 2014 03:56:50 +0000

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 detailed responses below:

Comment_1 & 2 – I wasn't sure what you found unclear here
Comment_8 – the text immediately above the diagram explains the horizontal axis and then the vertical axis.
Comment_9 -  the text immediately above the diagram already does elaborates on how the overlapping windows
Comment_12 – 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 EnergyMonitoringMIB AND the EnergyAwareMIB and this would be best placed in a separate document.
Comment_13 – compliance with SMIv2 can be assumed since the MIB imports from SNMPv2-SMI, correct?

Best Regards,

Brad

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
[email-masked] | www.coraid.com<http://www.coraid.com>
Coraid: Redefining Storage

From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, 31 Dec 2013 10:17:05 +0000
To: <[email-masked]<mailto:[email-masked]>>
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-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!

=> 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 relationship 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 elaborate on this in the text.

Comment_2: In section 5.2, page 20 is mentioned: “The Energy Object can be classified as consuming power or supplying power to other devices or that Energy Object can perform both of those functions, ..”. However, in the formal MIB definition on page 20, eoPowerCategory 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.

==============================

=> 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 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 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 representing the relations in the powerAttributeMIB are (probabl)  part of the ENERGY-OBJECT-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 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 is 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 might 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+L). You can then explain that the value of the EoEnergyConsumed is obtained 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 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 Energy Object, including the Energy Object relationships. Is it possible to provide an example of the IANAEnergyRelationship (in particular regaring aggregation) defined in [ENERGY-AWARE-MIB].

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

Best regards,
Georgios Karagiannis

________________________________
Van: eman [[email-masked]<mailto:[email-masked]>] namens Thomas Nadeau [[email-masked]<mailto:[email-masked]>]
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-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 <[email-masked]<mailto:[email-masked]>> 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 hope they will be OK even if a few hours late.
> Thanks,
>    Juergen
>
>> -----Original Message-----
>> From: eman [mailto:[email-masked]] 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-mib-
>> 08 and draft-ietf-eman-energy-aware-mib-13
>>
>>
>>       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
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/eman
>
>

_______________________________________________ eman mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/eman

---

From: Brad Schoening <[email-masked]>
Date: Wed, 19 Feb 2014 04:29:13 +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" <[email-masked]> 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]
>          |     | 
>          |     +-- 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 
>   numbers in the MIB are 2, 3, and 4.  Perhaps the MIB table should be
>fixed 
>   so the column numbers are 1, 2, and 3.
>   
>
>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 
>   is a corresponding set of entries in this table, one entry for each
>power 
>   state supported by the Energy Object."
>  
>
>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 
>the following objects?
>
>   Page 58, "eoACPwrAttributesThdAmpheres":
>   Page 60, "eoACPwrAttributesPhaseAvgCurrent":
>   Page 62, "eoACPwrAttributesDelPhaseToNextPhaseVoltage":
>   Page 63, "eoACPwrAttributesWyePhaseToNeutralVoltage":
>   Page 64, "eoACPwrAttributesWyePhaseCurrent":
>                  
>
>Page 59, "eoACPwrAttributesPhaseEntry":
>   
>   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
>
> 
>--------------------------------------------------------------------------
>----
> 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/
> 
>--------------------------------------------------------------------------
>----
>
>[email-masked]

---

From: Brad Schoening <[email-masked]>
Date: Wed, 19 Feb 2014 04:42:49 +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" <[email-masked]> 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
>
>
>> 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
>> 
>>

---

From: Ira McDonald <[email-masked]>
Date: Thu, 20 Feb 2014 12:51:23 -0500

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 <[email-masked]> 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.
>

<ira> OK </ira>

>
>  #54 - for a 15 minute measurement interval, 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 described (useful for
> statically allocated tables, using 'notInService' for a toggle)
>

<ira>
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.
</ira>

>  #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)
>

<ira>
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?
</ira>

>
>   From: Ira McDonald <[email-masked]>
> Date: Mon, 30 Dec 2013 09:58:36 -0500
> To: Thomas Nadeau <[email-masked]>, Ira McDonald <
> [email-masked]>
> Cc: eman mailing list <[email-masked]>
>
> 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: [email-masked]
> 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 <[email-masked]>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
>> 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
> [email-masked]://www.ietf.org/mailman/listinfo/eman
>