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

[Thomas Nadeau <[e-mail]>]

	Juergen,

	Apologies but our emails crossed inflight it seems. 

> Hi Benoit,
> 
> Thank you for your replies on all technical comments.
> 
> I have two issues with the replies. One is stated in the email 
> below, the other one will come in a separate email.
> 
> Energy Management Domain
> ======================
> 
> The eman framework states: "An Energy Object should 
> be a member of a single Energy Management Domain".
> 
> Now and draft-ietf-eman-energy-aware-mib sharpens this to
> "Each Energy Object MUST belong to a single Energy 
> Management Domain".
> 
> This change from "should" to "MUST" is inappropriate.
> 
> The situation is that Cisco's EnergyWise uses a single domain 
> while some other products use multiple domains. We went 
> on with the recommendation for a single domain in the 
> framework because of the positive experience with 
> EnergyWise and no reported complaints on this from 
> EnergyWise customers.
> 
> But no technical argument was ever given for restricting a
> device to be member of a single domain only. In contrary, 
> I reported from applications of the multiple domain approach 
> without anyone challenging this technically.
> 
> The compromise in the framework was to recommend the 
> EnergyWise approach but not to completely exclude competing 
> approaches.
> 
> With a change from "should" to "must" you changed a lot in 
> this game. I do not see any _technical_ reason for this step.
> 
> In my comments I suggested a way that only needs a small 
> modification of one object's DESCRIPTION clause to be open
> for other implementations using multiple domains. My proposal
> still kept the recommendation for using a single domain only
> (even in the absence of a technical reason for this) but showed
> how to act if you have a strong need for multiple ones.
> 
> I propose to stay with the compromise achieved in the framework
> document and leave the door open for implementations that
> have (as RFC 2119 says) "valid reasons in particular circumstances"
> to choose a multi-domain approach.

	As I pointed out in my email just now, there are a number of
implications to the proposed change as well as the currently 
misaligned state of things.  After the chairs reviewed the situation
in detail including the history of the compromise, we felt that 
the consensus for the approach was in fact to go with a single 
domain. The reasoning was simple: the compromise that was made quite a
long time ago to converge on the single domain approach. It seems that 
the text in the Framework was not aligned with this decision. 
This is my in my previous email the chairs asked that The Framework 
document be changed to use MUST (and aligned the other sentence with 
the 1:1 comment", as well as align the text in the MIB.

	Tom/Nevil



> 
> Best regards,
>    Juergen
> 
> 
>> -----Original Message-----
>> From: Benoit Claise [mailto:[e-mail]]
>> Sent: Freitag, 17. Januar 2014 17:20
>> To: Juergen Quittek; 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 Juergen,
>> 
>> Thanks for your thorough review.
>> 
>> 	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.
>> 
>> Not sure this is correct. RFC 6933 allows a zero-length string. See the second
>> paragraph below.
>> 
>> entPhysicalName OBJECT-TYPE
>>    SYNTAX      SnmpAdminString
>>    MAX-ACCESS  read-only
>>    STATUS      current
>>    DESCRIPTION
>>            "The textual name of the physical entity.  The value of this
>>            object should be the name of the component as assigned by
>>            the local device and should be suitable for use in commands
>>            entered at the device's `console'.  This might be a text
>>            name (e.g., `console') or a simple component number (e.g.,
>>            port or module number, such as `1'), depending on the
>>            physical component naming syntax of the device.
>> 
>>            If there is no local name, or if this object is otherwise
>>            not applicable, then this object contains a zero-length
>>            string.
>> 
>>            Note that the value of entPhysicalName for two physical
>>            entities will be the same in the event that the console
>>            interface does not distinguish between them, e.g., slot-1
>>            and the card in slot-1."
>>    ::= { entPhysicalEntry 7 }
>> 
>> However, this sentence below is badly expressed
>> 
>>  Every Energy Object MUST have a printable name assigned to it.
>> This sentence actually means that if an assigned name is used, it must be a
>> printable one.
>> However, I wonder if this that sentence is needed at all, because we overrule
>> the entPhysicalName definition from the ENTITY-V4 RFC.
>> 
>> On top of that, with SnmpAdminString, we should be good, no?
>> 
>> from http://www.ietf.org/rfc/rfc3411.txt,
>> SnmpAdminString ::= TEXTUAL-CONVENTION
>>    DISPLAY-HINT "255t"
>>    STATUS       current
>>    DESCRIPTION "An octet string containing administrative
>>                 information, preferably in human-readable form.
>> 
>>                 To facilitate internationalization, this
>>                 information is represented using the ISO/IEC
>>                 IS 10646-1 character set, encoded as an octet
>>                 string using the UTF-8 transformation format
>>                 described in [RFC2279].
>> 
>>                 Since additional code points are added by
>>                 amendments to the 10646 standard from time
>>                 to time, implementations must be prepared to
>>                 encounter any code point from 0x00000000 to
>>                 0x7fffffff.  Byte sequences that do not
>>                 correspond to the valid UTF-8 encoding of a
>>                 code point or are outside this range are
>>                 prohibited.
>> 
>>                 The use of control codes should be avoided.
>> 
>>                 When it is necessary to represent a newline,
>>                 the control code sequence CR LF should be used.
>>                 The use of leading or trailing white space should
>>                 be avoided.
>> 
>>                 For code points not directly supported by user
>>                 interface hardware or software, an alternative
>>                 means of entry and display, such as hexadecimal,
>>                 may be provided.
>> 
>>                 For information encoded in 7-bit US-ASCII,
>>                 the UTF-8 encoding is identical to the
>>                 US-ASCII encoding.
>> 
>>                 UTF-8 may require multiple bytes to represent a
>>                 single character / code point; thus the length
>>                 of this object in octets may be different from
>>                 the number of characters encoded.  Similarly,
>>                 size constraints refer to the number of encoded
>>                 octets, not the number of characters represented
>>                 by an encoding.
>> 
>>                 Note that when this TC is used for an object that
>>                 is used or envisioned to be used as an index, then
>>                 a SIZE restriction MUST be specified so that the
>>                 number of sub-identifiers for any object instance
>>                 does not exceed the limit of 128, as defined by
>>                 [RFC3416].
>> 
>>                 Note that the size of an SnmpAdminString object is
>>                 measured in octets, not characters.
>>                "
>>    SYNTAX       OCTET STRING (SIZE (0..255))
>> 
>> Proposal, to make it clear that printable names are really a plus:
>> OLD:
>> 	 "Every Energy Object MUST have a printable name assigned to it"
>> NEW:
>> 	 "While entPhysicalName does allow zero-length name, every Energy
>>         Object should have a printable name assigned to it"
>> 
>> 
>> 
>> 	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).
>> 
>> Thanks for catching this discrepancy.
>> The framework mentions on one side:
>> 
>>        The Energy Object (Class) contains a string attribute to
>>        indicate membership in an Energy Management Domain.
>> It's true that this framework sentence contradicts this:
>> 
>>        An Energy Object should be a member of a single Energy
>>        Management Domain therefore one attribute is provided.
>> 
>> This last sentence doesn't reflect what was discussed at
>> http://www.ietf.org/mail-archive/web/eman/current/msg02033.html
>> 
>> 
>> 	JP : We've discussed this at length and the approach we chose was to
>> use a vector for the keywords to allow for further defining context you
>> describe. We proposed scalar for the PRIMARY category and the PRIMARY
>> role.
>> 
>> 
>> And, most importantly, http://www.ietf.org/mail-
>> archive/web/eman/current/msg02037.html, which is the outcome of the
>> authors call, supervised by Nevil:
>> 
>> 
>> 	*** Scalar vs Vector
>> 	       Category  - overloaded if vectore { cons, prod, meter, distributor,
>> store }
>> 	            Primary is better received
>> 	        ex: car { biz, pleasure, commute }
>> 	       Role - need semantic not vector
>> 	       Location? (new) - clearly not vector but semantic like rfc4776
>> better geo-priv
>> 	       Domain - no problem we discussed and went with single
>> 	Experience in filed is that scalar was only needed for these.
>> 	ref point lldp : brad
>> 
>> 
>> The framework should correct this sentence:
>> OLD:
>> 
>>        An Energy Object should be a member of a single Energy
>>        Management Domain therefore one attribute is provided.
>> NEW:
>> 
>>        An Energy Object must be a member of a single Energy
>>        Management Domain therefore one attribute is provided.
>> 
>> 
>> 
>> 	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.
>> 
>> Ack, will provide some new text
>> 
>> 
>> 
>> 	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 ;-)
>> 
>> This is a badly written sentence.
>> Proposal: remove
>> 
>> 
>> 	"Since the communication between the Energy Objects may not be
>> 	SNMP and is left to the choice of the device manufacturer"
>> 
>> 
>> 
>> 	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."
>> 
>> New text will be proposed.
>> 
>> 
>> 
>> 	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"
>> 
>> fixed
>> 
>> 
>> 
>> 
>> 	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).
>> 
>> See point 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.
>> 
>> See point 2, for the justification, discussed at the [EMAN-FMWK] time, on why
>> not to do this.
>> 
>> 
>> 
>> 	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.
>> 
>> The use of the "manufacturer" word is a poor choice.
>> This corresponds to section 5.3:
>> 
>>        The eoAlternateKey alternate key object specifies a manufacturer
>>        defined string that can be used to identify the Energy Object.
>>        Since an EnMS may need to correlate objects across management
>>        systems, this alternate key is provided to facilitate such a
>>        link.  This optional value is intended as a foreign key or
>>        alternate identifier for a manufacturer or EnMS to use to
>>        correlate the unique Energy Object Id in other systems or
>>        namespaces. If an alternate key is not available or is not
>>        applicable then the value is the zero-length string.
>> 
>> Proposal: change to "alternate"
>> 
>> In section 5.3
>> OLD:
>> 
>>        The eoAlternateKey alternate key object specifies a manufacturer
>>        defined string that can be used to identify the Energy Object.
>> NEW:
>>        The eoAlternateKey object specifies an alternate key string
>>        that can be used to identify the Energy Object.
>> OLD:
>> 
>>      eoAlternateKey OBJECT-TYPE
>>            SYNTAX          SnmpAdminString
>>            MAX-ACCESS      read-write
>>            STATUS          current
>>            DESCRIPTION
>>               "This object specifies a manufacturer defined string that
>>               can be used to identify the Energy Object.
>> NEW:
>> 
>>      eoAlternateKey OBJECT-TYPE
>>            SYNTAX          SnmpAdminString
>>            MAX-ACCESS      read-write
>>            STATUS          current
>>            DESCRIPTION
>>               "This object specifies an alternate key string
>> 
>> 
>> 
>> 
>> 	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.
>> 
>> ok.
>> 
>> 
>> 
>> 
>> 	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.
>> 
>> That makes sense.
>> 
>> 
>> 
>> 
>> 	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."
>> 
>> Good catch.
>> 
>> 
>> 
>> 
>> 	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?
>> 
>> OLD:
>> 
>>        IANAEnergyRelationship ::= TEXTUAL-CONVENTION
>>            STATUS            current
>>            DESCRIPTION
>>                    "An enumerated value specifies the type of
>>                     relationship between Energy Objects.
>> NEW:
>> 
>>        IANAEnergyRelationship ::= TEXTUAL-CONVENTION
>>            STATUS            current
>>            DESCRIPTION
>>                    "An enumerated value specifying the type of
>>                    relationship between an Energy Object A, on which
>>                    the relationship is specified, with the Energy Object B,
>>                    characterized by the UUID."
>> 
>> 
>> 	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.
>> 
>> Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregation
>> relationship as a summation. I guess you want some more text in this section
>> 5.4?
>> 
>> 
>> 
>> 
>> 	=================
>> 	Editorial comments:
>> 	=================
>> 
>> All these will be taken care of.
>> 
>> Thanks again.
>> 
>> Regards, Benoit.
>> 
>> 
>> 
>> 
>> 	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
>> 
>> 
>> 
>> 		-----Original Message-----
>> 		From: eman [mailto:[e-mail]] 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
>> 
>> 
>> 
>> 	_______________________________________________
>> 	eman mailing list
>> 	[e-mail]
>> 	https://www.ietf.org/mailman/listinfo/eman
>> 	.
>> 
>> 
> 
> _______________________________________________
> eman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eman
>