Subject: [eman] Comments on draft-ietf-eman-energy-aware-mib-07.txt

From: Alan Luchuk <[email-masked]>
Date: Wed, 13 Mar 2013 15:05:15 -0400 (EDT)

Hello,

Based upon review and prototyping the ENERGY-OBJECT-CONTEXT-MIB from
draft-ietf-eman-energy-aware-mib-07.txt, here are a few comments.
I hope these are helpful to the IETF EMAN WG.

Sincerely,
--Alan

Page 12, Section 5.4, "Energy Object Relationships"
---------------------------------------------------

The last sentence reads:

        Since the communication between the Energy Object Parent and
        Energy Object Child may not be via SNMP (as defined in EMAN-

Does this mean that SNMP is forbidden and is not allowed, or does it
mean that the communication may be by a protocol other than SNMP?

Page 17, under the EnergyObjectKeywordList textual convention:
--------------------------------------------------------------

The last sentence of the first paragraph reads:

         "White spaces before and after the commas are excluded, as 
          well as within a keyword itself."

Should the word "excluded" perhaps be changed to "ignored"?

An example that shows one or more keywords with embedded spaces (or
other special characters) would clarify the handling of these characters,
e.g., "customer support".

Page 24, under the eoRelationID MIB object:
-------------------------------------------

If an energy object cannot auto-discover the eoRelationID, but the
eoRelationID is known to the EnMS, how can eoRelationID be configured?
Should this object perhaps have a MAX-ACCESS of read-write?

What does a zero-length value of eoRelationID mean?   The DESCRIPTION
of the UUIDorZero TC includes the following:

     The semantics of the value zero-length OCTET STRING are
     object-specific and must therefore be defined as part of
     the description of any object that uses this syntax."

The DESCRIPTION text for the eoRelationID MIB object might be harmonized 
with the DESCRIPTION text for the eoProxyID a bit better.

Page 25, under the eoProxyID MIB object:
----------------------------------------

Same comments as for the eoRelationID object.

Page 27, under energyAwareMIBFullCompliance:
--------------------------------------------

If I'm comprehending the energyAwareMIBFullCompliance (and the energy-
AwareMIBReadOnlyCompliance) statements correctly, then the energyAware-
RelationTableGroup is a mandatory group.  The energyAwareRelationTableGroup
includes the the eoRelationID and eoRelationship MIB objects.

The eoRelationID and eoRelationship MIB objects are read-only.  If
the energy object cannot auto-discover the values for these two 
objects, and they cannot be populated by the EnMS, then these objects
must be implemented (adding cost) and populated with empty values (
providing no benefit.)  

Page 29 under the energyAwareOptionalMIBTableGroup OBJECT-GROUP:
----------------------------------------------------------------

The energyAwareOptionalMIBTableGroup includes the MIB objects eoMgmtMac-
Address, eoMgmtAddressType, eoMgmtAddress.  Should these be split into 
their own OBJECT-GROUP?  Many systems may be able to easily implement 
these objects, but not be able to implement the eoEthPortIndex, 
eoEthPortGrpIndex, and eoLldpPortNumber objects.

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 [email-masked]           Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------