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

[Ballot discuss]
The draft still calls out some use cases that appear out of scope, especially after the discussion around the EMAN MIB document. This DISCUSS is a placeholder to address one of the author's suggestion to delete: 1) the use cases in section 2.7 last paragraph (net-zero building), 2) 2.12 (off-grid devices), and 3) 2.14 (power capping).

[Ballot comment]
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.

[Ballot comment]
- 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.

[Ballot discuss]
[edited to fix missing word]

I agree with Stephen's comments that the security considerations are sorely lacking. I understand his reasoning for not asking the group to do considerably more work at this point in the process. But I'd like to see at least an explicit mention that power management as described in some of the use cases in this draft may have significant privacy considerations--even if that mention takes the form of "We haven't fully analyzed privacy issues, and leave that work to a follow on effort."

If, on the other hand, people think there aren't privacy issues, I'd like to see that assertion along with supporting arguments.

[Ballot discuss]
I agree with Stephen's comments that the security considerations are sorely lacking. I understand his reasoning for not asking the group to considerably more work at this point in the process. But I'd like to see at least an explicit mention that power management as described in some of the use cases in this draft may have significant privacy considerations--even if that mention takes the form of "We haven't fully analyzed privacy issues, and leave that work to a follow on effort."

If, on the other hand, people think there aren't privacy issues, I'd like to see that assertion along with supporting arguments.

[Ballot comment]

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":-)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-eman-applicability-statement-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Energy Management (EMAN) Applicability Statement) to Proposed Standard


The IESG has received a request from the Energy Management WG (eman) to
consider the following document:
- 'Energy Management (EMAN) Applicability Statement'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-03-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


        The objective of Energy Management (EMAN) is to provide an
        energy management framework for networked devices.  This
        document presents the applicability of the EMAN information
        model in a variety of scenarios with cases and target devices.
        These use cases are useful for identifying requirements for the
        framework and MIBs.  Further, we describe the relationship of
        the EMAN framework to relevant other energy monitoring standards
        and architectures.

        We are rerunning the last-call to account for the change to proposed
        standard and to address changes accumulated from 08 to 10

        http://www.ietf.org/rfcdiff?url1=draft-ietf-eman-applicability-statement-08&difftype=--html&submit=Go%21&url2=draft-ietf-eman-applicability-statement-10


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
-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.

[Ballot comment]
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.

[Ballot comment]

- 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":-)

[Ballot comment]
I'm balloting No Objection assuming that this draft is relabeled as a use case draft (I share Brian's confusion and support his Discuss about the document being an applicability statement, but if it's

[Ballot discuss]
I need someone to provide some clarity on this document.  It calls itself an applicability statement, but is categorized as Informational.  An IETF applicability statement is supposed to be a standards track document.  However, this document reads more like a combination of use cases and requirements.  If it is really meant to be an AS, then we need to re-start the process and issue a new last call as a standards track document.  If it is meant to be more requirements and use cases, the text should be updated to stricken the mention of applicability statement throughout.

[Ballot discuss]
2.7 (last paragraph) and 2.12 - I do not believe that EMAN is meeting these use cases. This goes back to my comments on the battery MIB. I think these use cases should be specifically called out in section 5 as *out of scope* for EMAN. EMAN does not provide the level of configuration and monitoring for a home or off-grid *generation* system.

[Ballot discuss]
-- Section 9.2 --
You have a bunch of references that lack citations to them, or for which the citations are incorrect. "[DASH]" is in the references, for example, but the citation is "[DSP0232]".  You have two references for DSP1027, and one incorrect citation for it.  The reference for [EMAN-MONITORING-MIB] has an incorrect document filename; the correct name is "draft-ietf-eman-energy-monitoring-mib".  There are more.  We should not be shoving it at the RFC Editor to fix these; please take care of this before the document is approved.

[Ballot comment]
Minor comments that I hope you'll please consider:

-- Section 1.2 --

        The EMAN working group charter called for producing a series of
        Internet standard drafts in the area of energy management.  The
        following drafts were created by the working group. 

I'm not fond of references in the RFCs to what the WG charter said.  Charters change and working groups go away, but RFCs are permanent.  Also, these are not "Internet Standard" as the IETF designates that, so why not avoid misunderstandings?  Also also, they will no longer be drafts when they're published as RFCs.  Simplifying to this should be good:

NEW
        The EMAN work consists of the following Standards Track and
        Informational documents in the area of energy management:
END

On the [EMAN-AS] reference: it seems very odd for this document to have a reference to itself.  The list headings also aren't separated from the explanatory text, which makes the list read oddly.  I suggest doing it this way, also using the complete titles of the documents:

NEW
          "Energy Management (EMAN) Applicability Statement" (this
          document) presents use  cases and scenarios for energy
          management.  In addition, other  relevant energy standards
          and architectures are discussed.

          "Requirements for Energy Management" [EMAN-REQ] presents
          requirements of energy management and the scope of the
          devices considered. 
         
          "Energy Management Framework" [EMAN-FRAMEWORK] defines a
          framework  for providing energy management for devices
          within or connected to communication networks,

          [...etc...]
END

For the energy-aware MIB explanation, change "proposes" to "defines"; for the battery MIB explanation, change "contains" to "defines".

-- Section 1.4 --
I find it odd that "energy management" or "energy control" seem always to refer to a reduction in energy use.  First, is there a reason there are two terms?  Second, I would think that energy management involves adjusting the energy usage appropriately, whether that be up or down -- turning the cooling up when necessary, as well as down when you can.  So I would say that energy management is desirable always... not just during low utilization or high demand periods.

-- Section 2.1 --
ENTITY-MIB needs to cite [RFC6933].

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-eman-applicability-statement-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Energy Management (EMAN) Applicability Statement) to Informational RFC


The IESG has received a request from the Energy Management WG (eman) to
consider the following document:
- 'Energy Management (EMAN) Applicability Statement'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


        The objective of Energy Management (EMAN) is to provide an
        energy management framework for networked devices.  This
        document presents the applicability of the EMAN information
        model in a variety of scenarios with cases and target devices.
        These use cases are useful for identifying requirements for the
        framework and MIBs.  Further, we describe the relationship of
        the EMAN framework to relevant other energy monitoring standards
        and architectures.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

Document:  draft-ietf-eman-applicability-statement-08
Title:    Energy Object Context MIB
Editors:  Brad Schoening, Mouli Chandramouli and Bruce Nordman
Intended status:  Informational

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?
    Why is this the proper type of RFC?  Is this type of RFC
    indicated in the title page header?

Informational.  This is the last of the EMAN WG drafts, it provides
a complete overview of EMAN, and provides clear guidance for its
potential uses.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

Technical Summary:
  The objective of Energy Management (EMAN) is to provide an
  energy management framework for networked devices.  This
  document presents the applicability of the EMAN information
  model in a variety of scenarios with cases and target devices. 
  These use cases are useful for identifying requirements for the
  framework and MIBs.  Further, we describe the relationship of
  the EMAN framework to relevant other energy monitoring standards
  and architectures.

Working Group Summary

Version -00 of the draft was published in December 2011, shortly
after the WG was chartered.  The authors (and WG chairs) felt that
since there were many aspects of EMAN that neededed a lot of
discussion, it would be sensible to publish its Applicability
Statement after all the other EMAN drafts.

Document Quality

This draft has been revised at intervals as details of EMAN were
finalised.  It's WG Last Call for version 06 ran from 26 June 2014 to
2 July 2014.  Since then it's authors have made further revisions,
in response to its ongoing discussion.

Personnel

Document Shepherd:        Nevil Brownlee
Responsible Area Director: Joel Jaegli

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd.  If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

I have read the draft carefully.  I believe it is a good overall
summary of EMAN, with realistic use cases and a good survey comparing
it with similar existing energy-related standards.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area
    Director and/or the IESG should be aware of? For example, perhaps
    he or she is uncomfortable with certain parts of the document, or
    has concerns whether there really is a need for it. In any event,
    if the WG has discussed those issues and has indicated that it
    still wishes to advance the document, detail those concerns here.

No known problems.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
    If so, summarize any WG discussion and conclusion regarding the
    IPR disclosures.

This draft has no IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

There is strong consensus for this draft within the EMAN WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

The nits checker gave a few warnings, I believe the RFC Editor will
fix those.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

This draft is a survey/summary document, it did not need any formal
reviews.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

No.

(15) Are there downward normative references references (see RFC
    3967)?  If so, list these downward references to support the Area
    Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries.  Confirm that any
    referenced IANA registries have been clearly identified. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

This draft has no IANA Considerations.

(18) List any new IANA registries that require Expert Review for
    future allocations. Provide any public guidance that the IESG
    would find useful in selecting the IANA Experts for these new
    registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

This draft has no formal material that can be chacked automatically.

-----