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

[Bruce Nordman <[e-mail]>]

John--
  Thanks much for carefully considering and replying to my comments.
While the document is improving, as you note, there are still many major
issues where we don't agree.  I do agree with you that further discussion
is not likely to change either of our minds so no need to invest time in
that.
  I still think that starting from the Energy Reporting draft
      draft-nordman-eman-er-framework-02<http://datatracker.ietf.org/doc/draft-nordman-eman-er-framework/>
would get us to a framework document suitable for passing WGLC faster
and with a higher quality result.  My concerns are still such that I don't
think
this version is suitable for WGLC.  However, if I am the only one on the
list
stating that then that is not sufficient to block progress.
  I trust you will all have a good and productive meeting.
  Best regards,
--Bruce


On Sun, Oct 13, 2013 at 3:02 PM, John Parello (jparello) <[e-mail]
> wrote:

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


-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov <http://nordman.lbl.gov>*
[e-mail]
510-486-7089
m: 510-501-7943