[eman] BNordman - draft-ietf-eman-framework-09: WGLC comments

["John Parello (jparello)" <[e-mail]>]

Hi Bruce,

Thanks so much for your comments. Considering your position on the draft I'll limit the comments applied to those that are or are near editorial. Those that indicate a previously stated approach counter to your proposal I'll leave so we don't have unnecessary debate or lobbying.

(+) Applied in the draft
(-) Regretfully not applied for the reasons listed
(!) Not applied needing more clarification and/or see further comment or thread


Thanks
Jp

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


The EMAN Framework draft is improving, as has been noted.  That said,
the comments below plus those in the review a few days ago from Juergen
Quittek indicate that the document still has far to go.  This list
is not comprehensive--that is not feasible with so much to address.
In addition, fixes that these comments lead to are likely to introduce
new issues or make clear existing ones that are not now readily apparent.
As this document has changed considerably over the past three+ years,
new issues continue to crop up.


Conceptual issues:

The mechanisms described for importance and role are non-standard and
arbitrary.  We might do well to have standard mechanisms for some
of these, but creating an anecdotal set solely in the context of EMAN
seems unlikely to contribute to that.  Until such time as there is some
basis for incorporating specific content, these should be left as
free-form keywords encoded in some standard syntax.

- JP : We gave guidance on that field.  Moving this to keywords with no standard syntax only moves your point to another attribute?.

The "relationship" concept is not necessary.  Simpler methods can express
what is required.  It makes the document harder to understand, and so
is a barrier to it being widely adopted.

- JP : We receive feedback that this was useful and we've carried this approach for some time

It is stated that a device should be labeled as "a consumer, producer,
or meter, distributor, or store of energy".  It isn't explained what the
value of making this distinction is.

! JP : we can expand on that but though the category was enough. Suggestions?

The concept of "caliber"is not needed; accuracy is sufficient.

- JP : This was our most asked for attributes. Accuracy for a device that does not use statistical nor physical (H/W) means to measure power is meaningless. We need a way to indicate which devices can or can't measure power (some based on table lookups for example) See any EnMS on their "power ratings"  Joulex, Nimsoft, Schneider etc. Also device manufacturers embraced this notion at ODVA and the Cisco implementation. Very much needed.

The draft states that a device must have at least two states: one
on state and one off state.  There are devices for sale that have
two states, on and sleep (but no off) and devices with only one
state.  Why have this restriction?  and why require a device to
report power states at all?  most will certainly but some might
appropriately not do so.

+ JP :  should


The explanation of power state semantics in 4.5 is not consistent
with general usage of the concept of power state.  Power limitation
may be useful, but it is a different concept from power state and
should not be conflated.

4.5.4. These are arbitrary.  It would be better to specify registration
of the Cisco power state set since that is presumably already in use.

4.6. Power Source Relationship and Metering Relationship are redundant.
As the text points out, both are about wiring topologies.

4.6.3. The second and last paragraphs seem to be contradictory as
to whether two non-connected PIs can have a Power Source Relationship.

4.6.3. It is not clear how metering is to be applied.

4.6.4. It is stated that "Establishing aggregation relationships within
the same device would make modeling more complex…".  The ER Framework
accomplishes this without any complexity burden, so the statement in
general is not true.  It may be true of the EMAN Framework but that is
simply a flaw in the document.

4.6.5. The text leaves "proxy" relationships for future development,
but there are requirements (8.1) for proxy control that the framework
seems to not cover.

6. It is stated that some products cannot support power interfaces.
Any device can and could simply report "unknown" for data they do not know.

6.1. The draft indicates that power interfaces can be between devices and
components.  This adds a lot of complexity to the PI concept.  It would
be much simpler to not allow PIs between components.  For those niche
applications that desire that, the component in question could be modeled
as a distinct device.  Thus, complexity of EMAN could be reduced without
sacrificing capability.

Aggregation:

4.6. It is completely unclear how the Aggregation Relationship mentioned
is supposed to operate.

4.6.4.  It is suggested that a device can report only a single aggregation.
Is that true?

6.3. explains what aggregation is, but not how it actually works.
The two sentences in the middle paragraph contradict each other.

Corrections:

The introductions states that "The framework introduces the concept of
a power interface".  This is not true.  The power interface concept
was introduced in draft-quittek-eman-reference-model-02, over two
years ago.  Also, the definition provided for Power Interface doesn't
make sense, and does not correspond to the concept described in the
Reference Model, or the ER Framework.  The latter has a clear explanation,
the first sentence of which could be a definition.

! JP : We merged that document with this and the authors are on this document. @Chairs can we reference a non-wg item that is expired, best way to footnote this?

The bulleted text under 4.5.2 on IEEE 1621 is wrong.  I have pointed
this out many many times without it being fixed.  Also, for 4.5.5,
IEEE 1621 does NOT say that hibernate is a form of sleep; it says that
hibernate should be presented as a form of off.  This error has also
been pointed out many times.

+ JP : changed to off in 4.5.5.  Section 4.5.2 now directly quotes IEEE1621 4.1
"""
The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary states: on, off or sleep.
In IEEE1621 devices are limited to the three basic power states — on, sleep, and off. Any additional power states are variants of one of the basic states rather than a fourth state.
"""

Details:

2. Definition of "Meter".  Change "intended to measure" to "that measures".
In general, what is the difference intended when "are intended to" is
used as opposed to what the referenced concepts actually do?

- JP : see IEC60050

Unnecessary text:

The document is burdened throughout by text that is unnecessary to
accomplish what is needed.  This makes reading it more difficult and
so would impede use of the standard.  An example is defining and
discussing Non-Electrical Equipment.  This is more appropriate to
an application/implementation discussion document, not a framework.
Other examples include the list of target devices in Section 3.1, all
of Section 3.4, sections 4.3.3, 4.3.4, 4.3.5, the second half of 4.3.6,
and the middle two paragraphs of 4.4.

The requirements RFC says:
5.5.1.  Energy Measurement
   The standard must provide means for reporting measured values of
   energy and the direction of the energy flow received or provided by
   an entity.  The standard must also provide the means to report the
   energy passing through each Power Interface.
The Framework says:
    4.4.3. Measurements: Energy
        Optionally, an Energy Object that can report actual power
        readings will have energy attributes that provide the
        energy used, produced, or stored in kWh.
Aside from noting that kWh are to be used, what is the point of saying
this at all?  and if this is about reporting energy, why does the text
talk about power?

! JP : Not sure how you can have energy values if you can't measure actual power. ANything you can suggest to make that clearer as you read it?

Thanks!
Jp