Ballot for draft-ietf-eman-applicability-statement
Discuss
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
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.
This version got a second last called as a proposed standard to address Brian's dicsuss.
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":-)