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

From: Thomas Nadeau <[email-masked]>
Date: Mon, 16 Dec 2013 10:56:01 -0500

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

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 17 Dec 2013 09:31:23 +0000

Dear Tom,
As an author I am not aware of any IPR that applies to draft-ietf-eman-energy-monitoring-mib and that has not yet been filed for this draft.
    Juergen

> -----Original Message-----
> From: eman [mailto:[email-masked]] 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
> 
> 
> 	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
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Dec 2013 15:36:52 +0100

Dear all,

Feedback regarding draft-ietf-eman-energy-monitoring-mib.
EMAN should start at 768 and not 1024, according to the 
IANAPowerStateSet TC.

                            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)

I should have probably spotted that one earlier. Sorry.

Regards, Benoit

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 30 Dec 2013 12:05:06 +0000

Dear all,

Below please find my comments on draft-ietf-eman-energy-aware-mib-13 titled "Energy Object Context MIB". I will send comments on draft-ietf-eman-energy-monitoring-mib-08 in a separate message.

==================
Technical comments:
==================

1) Section 5.1, 3rd paragraph: Since you are already very precise about this MUST, I would add that the name MUST NOT have length zero.

2) Section 5.1, one but last paragraph: "Each Energy Object MUST belong to a single Energy Management Domain or in other words, an Energy Object cannot belong to more than one Energy Management Domain." This is more strict than in the framework where we say an EO "should" not belong to more than one domain. However, as we have discussed several times, there are management systems that use more than one domain (different to EnergyWise). I do not see a good reason to declare that their model is wrong. Thus, we can recommend "make it as EnergWise from Cisco does it" with the "should" clause that we have in the framework, but we should not fully exclude other solutions with a "must" clause. See also comment 7).

3) Section 5.3, 2nd and 3rd paragraph:
Both paragraphs need more explanation and you need to make them consistent with the text in the MIB modules. For LLDP you say "If the LLDP MIB is implemented". Why don't you have a similar statement for the PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may not have SNMP agents, for example, if they are just a power interface. And it is not specified which of the potentially numerous instances of lldpLocPortNum objects of a device should be reported.

4) Section 5.4, 4th paragraph:
"Since the communication between the Energy Objects may not be 
SNMP and is left to the choice of the device manufacturer, an 
Energy Object can have additional MIB objects that can be used 
for easier identification by the EnMS."
Two comments on this sentence:
A) It is not very obvious if SNMP is not available, it makes sense to use MIB objects. Please clarify this.
B) Please note that the choice is not only with the manufacturer. Even if the manufacturer builds in SNMP, the operator may choose to disable it ;-)

5) Section 6, DESCRIPTION clause of object eoEthPortIndex:
What "attached device" are you talking about?
Why is it relevant for the specification of this object, if that a certain MIB module "should" be implemented on that device? Does it make any different for the DESCRIPTION of this object whether or not this MIB module is implemented on the attached device? I do not see why and thus recommend removing the statement "PoE MIB should be instantiated on the device."

6) Section 6, DESCRIPTION clause of object eoMgmtDNSName:
There may be more than one DNS name associated to a single IP address:
"the DNS name" -> "a DNS name"

7) Section 6, DESCRIPTION clause of object eoDomainName:
Please insert as second sentence: "If the energy object has been assigned to multiple domains, then they are represented in this object as comma-separated list.", see comment 2).

8) Section 6, SYNTAX clause of object eoPowerCategory:
Some devices match more than one category, for example a UPS is a store and a distributor at the same time, and to be precise, also a consumer. A PoE Switch is a consumer and a distributor, some devices switch between consumer and producer, etc. We can support all of this if we change the syntax from INTEGER to BITS.

9) Section 6, DESCRIPTION clause of object eoAlternateKey:
There is a contradiction between having this object with MAX-ACCESS read-write and stating " This object specifies a manufacturer defined string". If the manufacturer defines the string, there is no need to write it. I suggest allowing the operator to set the value of this document.

10) Section 6, DESCRIPTION clause of object eoRelationID:
I recommend adding a sentence to the DESCRIPTION clause, that preferable the value of an entPhysicalUUID from the Entity MIB should be used for values of this object.

11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: 
The dependence of compliance with entity4CRCompliance is stated in the GROUP DESCRIPTION clauses. In our case, this is not the right place. There is a dependency on entity4CRCompliance  independent of which group is implemented. Hence, these statements need to be moved from the GROUP DESCRIPTION clauses to the module compliance DESCRIPTION clauses of energyObjectContextMIBFullCompliance and energyObjectContextMIBReadOnlyCompliance.

12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module:
We state in other places that implementation of the Entity MIB compliant with entity4CRCompliance is a must. But in the conformance section of the ENERGY-OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is stated as "should". This need to be changed to a "must" or "required."

13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship:
For interoperability, the description need to be clear. As this TC is stated, there are two points unclear to me:
A) " The enumeration 'poweredBy' is applicable if the  
       Energy Object A is poweredBy Energy Object B. 
       The enumeration 'powering' is applicable if the  
       Energy Object A is powering Energy Object B."
If the TC is used, how do I know which object is A and which is B? Is it that the DESCRIPTION clauses of objects of this type must refer to object A and object B?
B) "if the Energy Object A is aggregating Energy Object B"
There is no place in this document where there is explained what aggregating means.

=================
Editorial comments:
=================

14) Abstract, last two lines:
"relationships between reporting devices, remote devices, and monitoring devices.": The enumeration of "reporting devices", "monitoring devices", and "remote devices" is inappropriate because it does not reflect the list of relationships discussed by the draft: poweredBy, meteredBy, aggregatedBy.

15) Section 1. Introduction, 2nd paragraph, last two lines:
"Identification" -> "identification"
"Context" -> "context"
"Relationships" -> "relationships"

16) Section 1.1, 3rd paragraph, line 1:
"A second MIB module required by the [EMAN-FMWK]": There is no MIB module required by the EMAN framework. It seems you wanted to say: "A second MIB module meeting EMAN requirements given by [RFC6988]".

17) Entire Section 3
This section is completely redundant. It mainly repeats sentences of section 1.1. Remove this section and merge sentences you want to keep into section 1.1

18) Section 5, 3rd paragraph, first sentence:
The sentence is not grammatically correct, please fix. Also semantic correction seems to be needed. You don't mention "identification" as focus of the first table.

19) Section 5, sentence before Figure 1:
"The following UML diagram illustrates the relationship of the 
MIB objects in the eoTable, eoRelationTable that describe the 
identity, context and relationship of an Energy Object."
You should mention that you UML diagram furthermore contains objects from the Entity MIB.

20) Section 5, figure 1:
There is a dotted line at the lower left that goes nowhere. Please cut it.

21) Section 5, grouping of MIB objects is inconsistent.
In Figure 1 you have three groups: "Context", "Identification", "Relationships", where "Identifications" has three subgroups. The sentence below the figure emphasizes this grouping. However, the following subsections 5.1-5.4 are grouped differently. 5.1 is titled "Identification" but covers only a third of the objects under "Identification" in Figure 1. Section 5.2 is consistently with Figure 1 covering context information. Section 5.3 covers PoE and LLDP identification. Sections 5.4 is called "Relationships" but covers not just the objects under "Relationships" in Figure 1, but also objects from under "Identification" in Figure 1. Here is a clean-up needed. Please split the last sentence from section 5.4. It firs much better in section 5.3.

22) Section 5, enumeration under Figure 1:
Please note that subsection 5.5 is not another group of MIB objects but refers to objects in subsection 5.1. The sentence above the enumeration implies that each numbered item would be a group of objects.

23) Section 5.1, 2nd paragraph, line 7:
What is "primary Energy Object information"? 

24) Section 5.4, 2nd paragraph, last sentence:
"It is important to notice, that it is possible that" -> "Obviously,"
"not have an" -> "not have any"

25) Section 5.4, 4th paragraph
The entire paragraph is in the wrong subsection. It rather belongs to subsection 5.1 or 5.3.

26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex:
See comment 5). There is a full stop missing at the end of the second sentence.

27) Section 6, OBJECTS clause of GROUP energyObjectRelationTableGroup:
The comment "Note that object eoRelationIndex is not included since it is not-accessible" is not really needed. Almost every Conformance section has such objects and usually this comment is omitted.

Cheers,
    Juergen

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 30 Dec 2013 08:43:55 -0500

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

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

---

From: Ira McDonald <[email-masked]>
Date: Mon, 30 Dec 2013 09:58:36 -0500

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
> numbering. Would the document editors please address these and republish
> the drafts ASAP so that we can proceed with progressing the drafts?
>
> 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
> >
> >

---

From: Ira McDonald <[email-masked]>
Date: Mon, 30 Dec 2013 10:01:58 -0500

Hi Thomas,

This is the link in the EMAN mailing list archive to those comments
that I sent three days ago on the Energy Monitoring MIB.

http://www.ietf.org/mail-archive/web/eman/current/msg02118.html

Cheers,
- Ira

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 30 Dec 2013 12:22:16 -0500

ok cool. I must have missed the email over the holiday.

thanks

Tom

> On Dec 30, 2013, at 9:58 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> Ahem - I did send the attached extensive comments on the Energy Monitoring MIB
>> On Mon, Dec 30, 2013 at 8:43 AM, Thomas Nadeau <[email-masked]> wrote:
>> 
>>         WG,
>> 
> <ira-comments-on-draft-ietf-eman-energy-monitoring-mib-08.pdf>

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 30 Dec 2013 18:46:05 +0000

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

> 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

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 30 Dec 2013 19:04:29 +0000

Dear all,

There are two more comments on draft-ietf-eman-energy-aware-mib-13 that I missed to include in my previous email.

One is editorial and one is technical:

Editorial: MIB modules description
It is just once mentioned that there are two MIB modules in this draft (Section 1.1, first sentence. The draft starts discussing the ENERGY-OBJECT-CONTEXT-MIB module and sometimes uses "this MIB modules" to refer to it. When the discussion of the other MIB module starts in the middle of section 5.4 it would be helpful adding a statement reminding the reader that this module is included in the draft as well. For example by changing in section 5.4, 3rd paragraph
OLD
        The IANA Energy Relationship MIB module specifies the first 
        version of the IANA-maintained definitions of relationships
NEW
        The IANA Energy Relationship MIB module in Section 6 below specifies the first 
        version of the IANA-maintained definitions of relationships

Technical: object eoPowerInterfaceType
I wonder why object eoPowerInterfaceType is included in the ENERGY-OBJECT-CONTEXT-MIB and not in the ENERGY-OBJECT-MIB itself. This object does not provide context, identity, or relationship information, but rather a technical property of a power interface, such as the nominal voltage or the number of AC phases. Why is it in this MIB module. Wouldn't it fit much better in the other one?

Cheers,
    Juergen

> From: eman [mailto:[email-masked]] On Behalf Of Juergen Quittek
> Sent: Montag, 30. Dezember 2013 13:05
> To: eman mailing list
> Below please find my comments on draft-ietf-eman-energy-aware-mib-13
> titled "Energy Object Context MIB". I will send comments on draft-ietf-eman-
> energy-monitoring-mib-08 in a separate message.
> 
> ==================
> Technical comments:
> ==================
> 
> 1) Section 5.1, 3rd paragraph: Since you are already very precise about this
> MUST, I would add that the name MUST NOT have length zero.
> 
> 2) Section 5.1, one but last paragraph: "Each Energy Object MUST belong to a
> single Energy Management Domain or in other words, an Energy Object cannot
> belong to more than one Energy Management Domain." This is more strict
> than in the framework where we say an EO "should" not belong to more than
> one domain. However, as we have discussed several times, there are
> management systems that use more than one domain (different to
> EnergyWise). I do not see a good reason to declare that their model is wrong.
> Thus, we can recommend "make it as EnergWise from Cisco does it" with the
> "should" clause that we have in the framework, but we should not fully exclude
> other solutions with a "must" clause. See also comment 7).
> 
> Both paragraphs need more explanation and you need to make them consistent
> with the text in the MIB modules. For LLDP you say "If the LLDP MIB is
> implemented". Why don't you have a similar statement for the PoE MIB? You
> talk about "the" Energy Object SNMP agent. However, EOs may not have SNMP
> agents, for example, if they are just a power interface. And it is not specified
> which of the potentially numerous instances of lldpLocPortNum objects of a
> device should be reported.
> 
> "Since the communication between the Energy Objects may not be SNMP and is
> left to the choice of the device manufacturer, an Energy Object can have
> additional MIB objects that can be used for easier identification by the EnMS."
> B) Please note that the choice is not only with the manufacturer. Even if the
> manufacturer builds in SNMP, the operator may choose to disable it ;-)
> 
> Why is it relevant for the specification of this object, if that a certain MIB
> module "should" be implemented on that device? Does it make any different
> for the DESCRIPTION of this object whether or not this MIB module is
> implemented on the attached device? I do not see why and thus recommend
> removing the statement "PoE MIB should be instantiated on the device."
> 
> Please insert as second sentence: "If the energy object has been assigned to
> multiple domains, then they are represented in this object as comma-separated
> list.", see comment 2).
> 
> Some devices match more than one category, for example a UPS is a store and
> a distributor at the same time, and to be precise, also a consumer. A PoE
> Switch is a consumer and a distributor, some devices switch between consumer
> and producer, etc. We can support all of this if we change the syntax from
> INTEGER to BITS.
> 
> There is a contradiction between having this object with MAX-ACCESS read-
> write and stating " This object specifies a manufacturer defined string". If the
> manufacturer defines the string, there is no need to write it. I suggest allowing
> the operator to set the value of this document.
> 
> I recommend adding a sentence to the DESCRIPTION clause, that preferable
> the value of an entPhysicalUUID from the Entity MIB should be used for values
> of this object.
> 
> The dependence of compliance with entity4CRCompliance is stated in the
> GROUP DESCRIPTION clauses. In our case, this is not the right place. There is a
> dependency on entity4CRCompliance  independent of which group is
> implemented. Hence, these statements need to be moved from the GROUP
> DESCRIPTION clauses to the module compliance DESCRIPTION clauses of
> energyObjectContextMIBFullCompliance and
> energyObjectContextMIBReadOnlyCompliance.
> 
> We state in other places that implementation of the Entity MIB compliant with
> entity4CRCompliance is a must. But in the conformance section of the ENERGY-
> OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is stated as
> "should". This need to be changed to a "must" or "required."
> 
> If the TC is used, how do I know which object is A and which is B? Is it that the
> DESCRIPTION clauses of objects of this type must refer to object A and object
> B?
> "relationships between reporting devices, remote devices, and monitoring
> devices.": The enumeration of "reporting devices", "monitoring devices", and
> "remote devices" is inappropriate because it does not reflect the list of
> relationships discussed by the draft: poweredBy, meteredBy, aggregatedBy.
> 
> "A second MIB module required by the [EMAN-FMWK]": There is no MIB
> module required by the EMAN framework. It seems you wanted to say: "A
> second MIB module meeting EMAN requirements given by [RFC6988]".
> 
> 17) Entire Section 3
> This section is completely redundant. It mainly repeats sentences of section 1.1.
> Remove this section and merge sentences you want to keep into section 1.1
> 
> The sentence is not grammatically correct, please fix. Also semantic correction
> seems to be needed. You don't mention "identification" as focus of the first
> table.
> 
> "The following UML diagram illustrates the relationship of the MIB objects in
> the eoTable, eoRelationTable that describe the identity, context and
> relationship of an Energy Object."
> In Figure 1 you have three groups: "Context", "Identification", "Relationships",
> where "Identifications" has three subgroups. The sentence below the figure
> emphasizes this grouping. However, the following subsections 5.1-5.4 are
> grouped differently. 5.1 is titled "Identification" but covers only a third of the
> objects under "Identification" in Figure 1. Section 5.2 is consistently with Figure
> 1 covering context information. Section 5.3 covers PoE and LLDP identification.
> Sections 5.4 is called "Relationships" but covers not just the objects under
> "Relationships" in Figure 1, but also objects from under "Identification" in
> Figure 1. Here is a clean-up needed. Please split the last sentence from section
> 5.4. It firs much better in section 5.3.
> 
> Please note that subsection 5.5 is not another group of MIB objects but refers
> to objects in subsection 5.1. The sentence above the enumeration implies that
> each numbered item would be a group of objects.
> 
> The comment "Note that object eoRelationIndex is not included since it is not-
> accessible" is not really needed. Almost every Conformance section has such
> objects and usually this comment is omitted.
> 
> Cheers,
>     Juergen
> 
> 
> completing
> > its WG LC the chairs would like to initiate a WG LC on draft-ietf-

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 30 Dec 2013 19:33:02 +0000

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

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 30 Dec 2013 14:52:36 -0500

The note said 8AM EDT. *)

	Anyways, send over your comments ASAP.

	--Tom

---

From: <[email-masked]>
Date: Tue, 31 Dec 2013 10:17:05 +0000

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]] namens Thomas Nadeau [[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

        --Tom