Subject: [eman] Comments on draft-ietf-eman-energy-aware-mib-03

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 15 Nov 2011 22:08:50 -0600

See below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
224 Brookhill Drive
Gahanna, OH  43230
Email: [email-masked]
Phone: 614 718 6308

-----------------------------------------------
Comments on draft-ietf-eman-energy-aware-mib-03
-----------------------------------------------

I will provide an annotated PDF file to the authors which should be easier to 
follow than the textual description below.  The PDF version also highlights 
some minor typos and simple wording changes which may not appear below.  The 
comments are broken down by sections, as indicated.

Section 5.1
-----------

> When a Energy Object Parent acts as a Power Aggregator or a
> Power Proxy, the Energy Object Parent and its Energy Object
> Child/Children MUST be members of the same Energy Management
> Domain, specified by the eoDomainName MIB Object.

An Energy Management Domain is currently defined to be simply a set of Energy 
Objects.  The definition provides examples of these nodes being loosely related 
to their belonging to the same power distribution tree (i.e. they are powered 
from the same source).  These examples are not prescriptive, however, so what 
is the rationale behind making this limitation?

I don't necessarily disagree but we should be able to articulate the reason why 
we need the restriction.

I think that this points to the need to refine the definition of Energy 
Management Domain a bit further to help clarify the basis for this 
restriction/requirement.

Also the existing assumption that an Energy Object is only associated with a 
single Energy Management Domain is still an open question from my perspective.  
My counter example is a device which has access to multiple power sources and 
which source is being utilized varies over time.  Each such source will 
presumably comprise it's own metering domain, no?

> Each Energy Object MUST belong to a single Energy Management Domain ...

I question whether this is a valid assumption.  We need to discuss this further.

> The eoMgmtMacAddress, eoMgmtAddress, eoMgmtAddressType, and
> eoMgmtDNSName MIB objects SHOULD be implemented for Energy
> Object Children, and MAY be implemented for Energy Object
> Parents.

Can you please clarify why there is a distinction between parents and children 
for these fields?

Section 5.3
-----------

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

Is a single alternate key sufficient?  Should this be a list of keys in the 
event that there are multiple management systems which need to utilize that 
correlation feature?

Section 5.4
-----------

> Each object contains the list of Energy Object Parent UUIDs for
> the specific Energy Object Relationship type. The UUIDs MUST
> comply to the RFC 4122 specifications. The object contains URIs
> and, therefore, the syntax of this object must conform to RFC
> 3986 [RFC3986], section 2. Multiple URIs may be present and are
> separated by white space characters. Leading and trailing white
> space characters are ignored.

Does the multiple URIs requirement apply to all of the defined relationship 
fields?  For example, can eoProxyBy have multiple URIs?  What about the other 
relationships?

> The eoParentProxyAbilities object is specific to the Proxy
> Relationship. This object describes the capabilities of the
> Energy Object Parent for the Energy Object Child represented by
> the entPhysicalIndex. The possible capabilities are: report,
> configuration, and/or wakeonlan. This object only applies to an
> Energy Object Child.

If there are multiple URIs in the eoProxyBy object what does this object 
contain?  A single set of abilities that applies to all the proxies, or a set 
of such capabilities which then map 1 to 1 with the proxies?  I would think 
that latter is more appropriate.  Do we need to address how this mapping is 
defined/realized?

Section 7
---------

> "A list of keywords that can be used to group Energy
> Objects for reporting or searching. If multiple keywords
> are present, then this string will contain all the
> keywords separated by the ',' character. For example, if
> a Energy Object were to be tagged with the keyword values
> 'hospitality' and 'guest', then the keyword list will be
> 'hospitality,guest'."

Should the include an explicit exclusion of the use of whitespace before and 
after the commas, and/or within a keyword itself?  Why are we limiting this to 
255 OCTETs?

> eoMeteredBy OBJECT-TYPE
> SYNTAX OCTET STRING

I note that in the case of keywords we defined an explicit textual convention 
whereas here we are using a raw OCTET STRING and relying on the object 
description to convey the syntax of the field.  Would it be better to also 
define a textual convention for these relationship fields which would then 
uniformly describe the conventions regardiong whitespace in one place?

> eoParentProxyAbilities OBJECT-TYPE
>     SYNTAX BITS {
>             none(0),
>             report(1),
>             configuration(2),
>             wakeonlan(3)
>         }

Since the eoProxyBy object can list multiple parents with the proxy 
relationship, what are the seamntics of this scaler field?  Do the same 
settings apply to all parents?  Would it be better to allow a per parent 
specification of the attribtues?