Subject: [eman] comments on the ENERGY-AWARE-MIB module in draft-ietf-eman-energy-aware-mib-04

From: Juergen Quittek <[email-masked]>
Date: Mon, 12 Mar 2012 15:13:43 +0000

Dear all,

Here are my comments on the ENERGY-AWARE-MIB module in
draft-ietf-eman-energy-aware-mib-04.  Again, I apologize for the
poor timing.  I will update my comments where the MIB module
Will change in version -05.

Module name:
I still think that the name "ENERGY-AWARE-MIB" is not descriptive.
Looking at the module description:
    "This MIB is used for describing the identity and the
     context information of Energy Objects"
Much better names would be
  ENERGY-OBJECT-IDENTITY-MIB
  ENERGY-OBJECT-CONTEXT-MIB
  ENERGA-CONTEXT-MIB
  ENERGY-OBJECT-RELATIONS-MIB
  ENERGY-RELATIONS-MIB
Actually, I would like the last one most.

IMPORTS:
It is a convenient common practice to list the RFC numbers as comments
behind the MIB names in the FROM clause.  This makes it easy for the
reader to find out which MIB module is in which document.
The references list as the end of the draft does not do so, because
There RFC numbers are linked with RFC titles but not with MIB module
names.  Here is an example from the BATTERY-MIB:
IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       mib-2, Integer32, Unsigned32
           FROM SNMPv2-SMI                                -- RFC2578
       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB                        -- RFC3411
       DateAndTime
           FROM SNMPv2-TC                                 -- RFC2579
       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
           FROM SNMPv2-CONF;                              -- RFC2580

EnergyObjectList ::= TEXTUAL-CONVENTION:
I am not happy with this TC defining a type of concatenated string
with URIs separated by white spaces.  It may turn out to be the best
Choice, but if possible, I would like to avoid it.

EnergyObjectList ::= TEXTUAL-CONVENTION, DESCRIPTION, lines 6-8:
  "Multiple URIs may be present and are separated by white
   space characters.  Leading and trailing white space
   characters are ignored."
For being interoperable, you must define what white spaces are.
Just blanks and tabs? Also CR and LF?

eoTablePersistence OBJECT-TYPE, DESCRIPTION:
You should be more specific about persistence.
"persistence" -> "persistence across re-initializations of the
local management subsystem"

eoTablePersistence OBJECT-TYPE, DESCRIPTION:
  "A value of
   True enables the persistence, while a value of False
   disables the persistence."
"True" -> true(1)
"False" -> fase(2)

eoTablePersistence OBJECT-TYPE, DESCRIPTION:
You should mention here that object eoKeywords is persistent
anyway independent from the value of this object.  See
DESCRIPTION clause of eoKeywords.

eoTablePersistence OBJECT-TYPE, DESCRIPTION:
We also have references to the Entitiy MIB, the PoE MIB, and the
LLDP MIB.  Would they also be persistent when the eoTable is
persistent?

eoEntry OBJECT-TYPE, DESCRIPTION
  "An entry describes the attributes of an Energy Object.
   Whenever a new Energy Object is added or deleted a row in
   the eoTable is added or deleted."
         
What means "a new Energy Object is added or deleted"?
Added to what?  Deleted from what?

"a new Energy Object is added or deleted" ->
"a new Energy Object is added or an existing one is deleted,"

EoEntry:
        EoEntry ::= SEQUENCE {
                eoEthPortIndex            m  PethPsePortIndexOrZero,
                eoEthPortGrpIndex         m  PethPsePortGroupIndexOrZero,
                eoLldpPortNumber          m  LldpPortNumberOrZero,
                eoDomainName              m  SnmpAdminString,
                eoRoleDescription         m  SnmpAdminString,
                eoMgmtMacAddress          o  MacAddress,
                eoMgmtAddressType         o  InetAddressType,
                eoMgmtAddress             o  InetAddress,
                eoMgmtDNSName             o  SnmpAdminString,
                eoAlternateKey            m  SnmpAdminString,
   
                eoKeywords                m  EnergyObjectKeywordList,
                eoImportance              m  Integer32,
                eoPowerCategory           m  INTEGER,
                eoMeteredBy               o  EnergyObjectList,
                eoPoweredBy               o  EnergyObjectList,
                eoDependentOf             o  EnergyObjectList,
                eoAggregatedBy            o  EnergyObjectList,
                eoProxyBy                 o  EnergyObjectList,
                eoChildrenList            o  EnergyObjectList
        }          

I added m=manadatory and o=optional to the entry spec above.
What you see is that There is that blocks of mandatory and optional
Columnar objects alternate.  This is not desirable because some
Management systems are sensitive to gaps in object numbering.
I would suggest having all mandators objects together at the top.

eoEthPortIndex, eoEthPortGrpIndex, eoLldpPortNumber, DESCRIPTIONs:
"This variable uniquely identifies the power Ethernet port ..."
You should discuss in which context this is "uniquely".
It is uniquely specified only in the context of an PoE PSD
That has the PoE MIB module instantiated.

eoDomainName, DESCRIPTION:
  "The value of eoDomainName must remain
   constant at least from one re-initialization of the
   entity's network management system to the next re-
   initialization."
"entity" is not well defined.
"entity's network management system" ->
"local management subsystem"

eoMgmtMacAddress, eoMgmtAddressType, eoMgmtAddress,
eoMgmtDNSName, DESCRIPTIONs:
  "The XXX MIB object SHOULD be implemented for
   Energy Object Children, and MAY be implemented for Energy
   Object Parents."
This conformance statement should be moved to or at least
repeated in the conformance section.

eoMgmtMacAddress, DESCRIPTIONs:
  "This object typically only applies to Energy
   Object Children."
Why? What is a typical parent without a MAC address?
Or is the "typical" parent a PoE switch with too many
MAC addresses?

eoMgmtMacAddress, eoMgmtAddress,
eoMgmtDNSName, DESCRIPTIONs:
  "This object can be used as an alternate
   key to help link the Energy Object with ..."
If this is the alternate key, what is the primary key?
Without mentioning the primary one, there is no point
in talking about "alternate".

eoMgmtAddressType, DESCRIPTIONs:
  "This object MUST be
   implemented when eoMgmtAddress is populated."
Here you mix "implementing with populating"
You may want to say "This object MUST be populated
when eoMgmtAddress is populate."

eoKeywords, DESCRIPTION:
The description asks for persistency independent of the
Value of object eoTablePersistence.  This should be
Explicitly mentioned here.

eoKeywords, DESCRIPTION:
  "This includes instantiations
   across all re-initializations/reboots of the network
   management system.
"network management system" ->
"local management subsystem"

eoPowerCategory, SYNTAX:
I assume this will be renamed to provider - receiver.

eoMeteredBy, DESCRIPTION
"When" -> "If"

eoMeteredBy, eoPoweredBy, eoDependentOf, eoAggregatedBy,
eoProxyBy, eoChildrenList, DESCRIPTIONs:
  "If this Energy Object is not an Energy Object Child, or
   if the Energy Object doesn't have a XXXXXX
   Relationship, the object is not instantiated.  A zero
   length octet string may also be returned in this case."
This is in conflict with the conformance section.  Here
you ask implementing each relationship individually
dependent on the existing relationships.  But according
to the conformance section the option is either implementing
none or all of them.
Anyway, if you keep these individual implementation constraints
They need to be moved to or repeated in the conformance section.

eoChildrenList, DESCRIPTION:
  "If this Energy Object is not an Energy Object Parent, the
   object is not instantiated.  A zero length octet string
   may also be returned in this case."
This is a contradiction.  If the first sentence is applied,
there is no alternative "in this case".

eoProxyAbilities, SYNTAX:
What is value none(0) useful for?
What is the difference between 1 0 0 0 and 0 0 0 0 ?
If there is none, value none(0) should be removed.

energyAwareMIBFullCompliance, DESCRIPTION:
  "When this MIB is implemented with support for
   read-create, then such an implementation can
   claim full compliance."
There is no object in the modules that has a MAX-ACCESS
of read.create.  "read-create" -> "read-write"

energyAwareMIBReadOnlyCompliance, SYNTAX:
"read-create" -> "read-write"

energyAwareMIBFullCompliance, energyAwareMIBReadOnlyCompliance,
DESCRIPTIONs:
  "Such devices can then
   be both monitored and configured with this MIB.
   The entPhysicalIndex, entPhysicalName, and
   entPhysicalUris [RFC4133] MUST be implemented."
I have concerns that this is acceptable.  Implementing
two columnar objects and an index of a table means that
entPhysicalTable is implemented.  And many tools will
detect the existence of the table by trying to access it.
But the implementation of this table would not be compliant
with any ENTITY-MIB compliance clauses.
Are we here promoting non-compliant implementations of the
Entity MIB?

Thanks,
    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Mon, 12 Mar 2012 16:36:09 +0100

Hi Juergen,

Many thanks for your thorough review of this draft.
That helps a lot.
>    ENERGY-OBJECT-CONTEXT-MIB
ENERGY-OBJECT-CONTEXT-MIB: We have a version almost ready to post that contains exactly this ;-)

>             FROM SNMPv2-CONF;                              -- RFC2580
Sure.
> Choice, but if possible, I would like to avoid it.
Let's list this as an open issue for now.
> Just blanks and tabs? Also CR and LF?
Let's list this as an open issue for now.
> local management subsystem"
Sure.
>     disables the persistence."
yes.
> DESCRIPTION clause of eoKeywords.
ok.
> LLDP MIB.  Would they also be persistent when the eoTable is
Good point, as you mentioned in your previous email.
> "a new Energy Object is added or an existing one is deleted,"
yes.
> I would suggest having all mandators objects together at the top.
ok, we could do this, and keep the UML in figure 1 to explain the 
logical grouping.
> That has the PoE MIB module instantiated.
yes.
> "local management subsystem"
yes.
> repeated in the conformance section.
ok.
> Or is the "typical" parent a PoE switch with too many
because it's more interesting to report a remote MAC (the one from a 
remote Energy Device) than your own, which you could find in another way.
> in talking about "alternate".
to be clarified.
> when eoMgmtAddress is populate."
ok.
> Explicitly mentioned here.
ok.
> "local management subsystem"
ok.
> I assume this will be renamed to provider - receiver.
should be
> They need to be moved to or repeated in the conformance section.
ok.
> there is no alternative "in this case".
to be clarified.
> If there is none, value none(0) should be removed.
I don't recall the justification.
> of read.create.  "read-create" ->  "read-write"
ok.
> Are we here promoting non-compliant implementations of the
Yes.
What is the alternative?
Redefine and duplicate OIDs. And then we have a different problem: 
incompatibility.

Regards, Benoit.
>
>
> Thanks,
>      Juergen
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

---

From: Ira McDonald <[email-masked]>
Date: Mon, 12 Mar 2012 11:41:08 -0400

Hi,

I'd like to comment on the TC "EnergyObjectList".

As Juergen Q has already noted, this TC is unwise.  What's whitespace?
SP, HT, VT, CR, LF? - fragile!  And very long strings in SNMP *are* an
implementation problem for limited embedded systems.

A table of URIs (w/ UUIDs) would be more appropriate.

Best practice would be to import URI-TC-MIB and then use a datatype
of either:

(a)  "Uri (SIZE (0 | 45))" - to allow for empty relationships; or

(b) "Uri (SIZE (45))" - to allow only RFC 4122 compliant values.

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

On Mon, Mar 12, 2012 at 11:13 AM, Juergen Quittek <[email-masked]> wrote:

> <...snip...>