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

From: Benoit Claise <[email-masked]>
Date: Fri, 27 Jan 2012 13:04:39 +0100

Hi Bill,

Thanks for your detailed review.
See in line.
> 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.
All inserted. Thanks.
>
> 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.
You're right. The current "Energy Management Domain" is not specific 
enough: it should contain the notion of management area. Here is a proposal:

      Energy Management Domain

         An Energy Management Domain is a set of Energy
         Objects where all objects in the domain are considered
	one unit of management.

         For example, power distribution units and all of the attached
         Energy Objects are part of the same Energy Management Domain.

Feedback?

Note that the [EMAN-FMWK] should expand on that.
>
> 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?
If they're not part of the same Energy Management Domain, you have the 
risk of double-counting in different domains, 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.
Sure.
>
>> 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?
We don't need this distinction any longer.
OLD:

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

NEW:

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

>
> 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?
If others are thinking that this is important, we could do this.
Personally, I believe one is enough
>
> 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?
We don't want to restrict eoProxyBy for a single Energy Object Parent, 
but that would make a lot of sense.
If not done, this should be clarified in [EMAN-FMWK]
>
>> 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?
See (*) below

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

> Why are we limiting this to
> 255 OCTETs?
You're right 255 is too short. Proposal: 2048

NEW:

EnergyObjectKeywordList ::= TEXTUAL-CONVENTION

STATUScurrent

DESCRIPTION

"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. 
_White spaces before and after the commas are excluded, as well as 
within a keyword itself. _

For example, if an Energy Object were to be tagged with the keyword 
values 'hospitality' and 'guest', then the keyword list will be 
'hospitality,guest'."

SYNTAX OCTET STRING (SIZE (0..2048))

------------------------------------------------------------------------

>
>> 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?
That makes sense.

EnergyObjectList ::= TEXTUAL-CONVENTION

STATUScurrent

DESCRIPTION

"A list of Energy Object Universally Unique Identifiers (UUIDs).

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, section 2.

Multiple URIs may be present and are separated by white space 
characters.Leading and trailing white space characters are ignored."

REFERENCE

"RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, section 
2, August 1998.

RFC 4122, Uniform Resource Identifier (UUID) URN Namespace, July 2005."

SYNTAX OCTET STRING (SIZE (0..2048))

Not sure about the length. How many UUID can we have in a list? Note 
that  "A UUID is 128 bits long" [RFC4122].
This Textual Convention would be applied to the following objects

               |  +-------------------------------------------+
               |--|   EO Child Relationships (optional)       |
               |  | ----------------------------------------- |
               |  |  eoMeteredBy (Parent(s) UUID list)        |
               |  |  eoPoweredBy (Parent(s) UUID list         |
               |  |  eoDependentOf (Parent(s) UUID list)      |
               |  |  eoAggregatedBy (Parent(s) UUID list      |
               |  |  eoProxyBy (Parent(s) UUID list)          |
               |  +-------------------------------------------+
               |
               |
               |  +-----------------------------------------+
               |--|   EO Parent Relationships (optional)    |
                  | --------------------------------------- |
                  |  eoChildrenList (Child(ren) UUID list)  |
                  +-----------------------------------------+

The object that would contain the most UUID is eoChildrenList. So how 
many Children can a parent have?
>
>> 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?
(*) This is the same issue as above.

Well spot: the eoParentProxyAbilities is specific per Energy Object 
Parent. So we need a new table for eoParentProxyAbilities, indexed not 
only by the entPhysicalIndex, but also by Energy Object Parent.

Regards, Benoit (as a contributor)
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 27 Jan 2012 13:50:59 -0500

Hi,

Thanks for your excellent review Bill.

Two comments:

(1) Single object string lengths greater than 1023 octets
might not pass over Ethernet links w/out fragmentation.
I would be cautious about using 2048 for TCs.

(2) While the UUID *itself* in RFC 4122 is 16 octets, the
total length expressed *as a URI* in the ABNF and example
on page 4 is exactly 45 octets:

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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