Energy Management (EMAN) Applicability Statement
draft-ietf-eman-applicability-statement-11

Nothing to add to the existing comments, but I would like us to discuss Brian's Discuss on the telechat.

I generally support the points raised by Brian, Pete, and Stephen.

It sounds like this document is going to get re-evaluated as a standards track Applicability Statement. I would suggest that the authors and WG consider the existing text in light of what is involved in an Applicability Statement (RFC 2026 Section 3.2) before that re-evaluation happens. In particular, an Applicability Statement is supposed to describe how, and under what circumstances, one or more technical specifications can be applied to support a particular Internet capability. There are several use cases in this document that provide no explanation of how the EMAN technical specifications can be applied to support the use cases, in particular the ones listed in 2.10, 2.11, and 2.12.

Editorial comment on Section 4.1.3:

"In particular, one of the concepts being considered
        different energy meters based on if the device consumes
        electricity, produces electricity, or is a passive device."
    
This sentence does not parse.

-09 seems to have corrected most of the bad references and citations, as far as I can tell by a fairly quick check.  One that remains: The reference for [EMAN-MONITORING-MIB] has an incorrect document filename; the correct name is "draft-ietf-eman-energy-monitoring-mib".

Thanks very much for handling that, and for addressing my other comments.

Thank you for addressing my DISCUSS. I've cleared.

- This draft (section 2) reads more like a collection of use cases than an applicability statement explaining how the EMAN framework can be applied to the different use cases. Only a few use cases provide guidelines wrt EMAN relationships between objects.
Let's take an blatant example, section 2.10 "industrial automation networks": where is the applicability statement in that section?
I started reading the document with a No Objection in mind, more like Alissa, who wrote:

    I would suggest that the authors and WG consider the
    existing text in light of what is involved in an Applicability Statement (RFC
    2026 Section 3.2) before that re-evaluation happens. In particular, an
    Applicability Statement is supposed to describe how, and under what
    circumstances, one or more technical specifications can be applied to support a
    particular Internet capability. There are several use cases in this document
    that provide no explanation of how the EMAN technical specifications can be
    applied to support the use cases, in particular the ones listed in 2.10, 2.11,
    and 2.12.

Then I thought about a DISCUSS, but Brad already proposed to delete the last paragraph of 2.7 and the sections 2.12 & 2.14. That would address my point. The alternative is to keep those section but to explain how the EMAN framework, as one building/foundational block, would help solving those use cases, and elaborate on which extensions would be required, even succinctly.

- What is your message with section 3? I guess you want to say that the EMAN framework (in his entirety of as a building) is applicable to all of these patterns, and that other energy use cases, not described in this document, with those parameters are potentially applicable to the EMAN framework.
You might want to stress this point.

Thank you for the updates to remove the out-of-scope use cases.

I support Stephen's comments and don't have any others to add since it use SNMP security and I hope we'll see more details in solution drafts.  Thanks for your work on this draft, the summary of work elsewhere was useful.

This is updated. The original comments were posted for -08
back in December. I don't believe I've ever seen any mail on
this one since. (Not unreasonable as Pete's discuss was 
being handled.) However, I don't see major changes between
-08 and -10 so I've not (yet, I will if time) gone fully back
over this again. It'd be nice (for me:-) if someone responded
to these comments as if they were made on -10 before the
telechat.

- general: I am not at all sure that this does match the
other EMAN documents that have been through IESG
evaluation (which is the stated reason for this being
last). See my comments below, but this seems to me to not
have been updated to reflect where the actual EMAN
drafts/RFCs ended up. Is that a fair comment? If so, it
really should at least be noted in this draft (or fixed!).
If not, then I'm confused and my memory must be worse than
I thought. 

- I support Pete's discuss

- general: I don't care much if the title confuses this
with an AS or not:-)

- general: Given the write-up would it be worth re-casting
this into the past tense? (Or a part of the abstract and
intro at least and then explaining the use of the present
tense elsewhere.)

- 1.3, 2nd last para: what is a proxy here?

- 1.5: EnMS vs NMS - aren't both likely to be pronounced
the same by some folks? Is this term used in other EMAN
docs? If not, maybe get rid of it as it'd not then be
needed perhaps?

- 2.11 - I don't recall printers being mentioned in other
EMAN docs, but that's probably my fallible memory.

- 2.12 - I thought these devices were out of scope for
EMAN? If so don't you need to say? If not, then can you
explain how I'm confused given that there were a bunch of
times Pete and I asked about energy harvesting setups and
were told those were not in scope?

- 4.1.2.1 - ACPI is mentioned twice but is never expanded
never mind explained. Given that this is the power state
thing with which most readers of this RFC will be
familiar, I think that is quite an omission, and one that
ought be fixed.

- 4.1.4 refers to a 2011 draft - surely that's been
updated or OBE by now? If "draft" here means something
sufficiently different from Internet-draft, then that'd be
worth explaining.

- section 4 generally seems quite US centric, which is a
pity. I'm not suggesting you try fix that now, but
nonetheless... a pity.

- section 5 seems quite outdated if I correctly recall the
discussions we had at iesg evaluation of other EMAN
documents. Why wasn't this kept in sync with those
discussions?

- section 6 is bogus - you said EMAN could also use YANG
so SNMP is not sufficient here. I would like to have seen
a real analysis of the security and privacy issues related
to energy management but that seems to still be missing.
And again if I recall correctly that was a topic that you
de-scoped for other EMAN documents. Yet again that is not
recoreded here.

- the secdir review [1] also notes the paucity of the
security considerations text (and was only responded
to by the AD, not by the authors, even though it 
raises some specific issues).

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05257.html

- The above two points are not DISCUSSes for a couple of
reasons. 1) the charter (sadly) doesn't explicitly call
for security or privacy to be considered and clearly this
group were not interested in those topics, and 2) there
seems to be no hope at all that such work would be done
given where the WG are in their life-cycle. I would hope
that any newly chartered work on energy management would
better take into account these real issues. (And should I
still be on the IESG, that'd be more than a "hope":-)