• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: eman

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

2013-05-08 02:49 Martin Stiemerling

[Ballot comment]
I have just checked -14 and I wonder about this text part:
"(the instantaneous power, as opposed to the demand, which is an averaged power),"

Power demand is not an average, as it is more complex than this. It also included peak power demand, etc.

2013-05-08 02:49 Martin Stiemerling

Ballot comment text updated for Martin Stiemerling

2013-05-08 02:14 Joel Jaeggli

State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup

2013-05-08 02:13 Joel Jaeggli

[Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli

2013-05-06 15:34 Stephen Farrell

[Ballot comment]
Thanks for addressing my discuss points

2013-05-06 15:34 Stephen Farrell

[Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss

2013-05-02 14:07 Benoit Claise

New revision available

2013-05-01 14:48 Stephen Farrell

[Ballot discuss]

Thanks: version -13 addresses all my discuss points except (3)
below, which I'd still like to discuss some more since I don't
think we've bottomed out on that.

(3) 6.1, 6.2 and section 8 may have serious consequences - are
we really ready to go straight there? I think the
authorization implied by this is maybe too onerous to attempt
now except in limited cases (e.g. a data centre's separate
control VLAN). I don't believe saying "sufficiently
protected" is enough, as you do in section 9. Again an
applicability statement might help here limiting these
features to networks that are reasonably well managed.

2013-05-01 14:48 Stephen Farrell

Ballot comment and discuss text updated for Stephen Farrell

2013-05-01 14:44 Stephen Farrell

[Ballot discuss]
Just a note that I don't think -12 addresses these discuss
points. I didn't check the comments.

(1) cleared

(2) cleared

(3) 6.1, 6.2 and section 8 may have serious consequences - are
we really ready to go straight there? I think the
authorization implied by this is maybe too onerous to attempt
now except in limited cases (e.g. a data centre's separate
control VLAN). I don't believe saying "sufficiently
protected" is enough, as you do in section 9. Again an
applicability statement might help here limiting these
features to networks that are reasonably well managed.

(4) cleared

2013-05-01 14:44 Stephen Farrell

Ballot discuss text updated for Stephen Farrell

2013-05-01 14:17 Richard Barnes

[Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss

2013-04-30 14:26 Benoit Claise

New revision available

2013-04-10 06:20 Benoit Claise

Shepherding AD changed to Joel Jaeggli

2013-03-14 13:26 Richard Barnes

[Ballot discuss]
Picking up Robert's DISCUSS...

There is a lot of text in this document that tries to constrain how to build an
Energy Management System, and don't have anything to do with placing
requirements on standards documents for interacting with what they measure. The
instance that elevated this to a DISCUSS for me is in 5.7 where the document
says "It should be avoided that time series data can only be obtained through
regular polling by the energy management system." Why should the IETF be making
such a statement in this document?

2013-03-14 13:26 Richard Barnes

[Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes

2013-03-04 06:26 Stephen Farrell

[Ballot discuss]

Just a note that I don't think -12 addresses these discuss
points. I didn't check the comments.

(1) Are sleepy nodes, power harvesting and self-controlling
devices included? (By self-controlling I mean devices that set
their own sleep-thresholds based on history.) They need to be
in some eventual standards. Maybe eman standards (and this
document) ought have some kind of applicability statement
limiting scope to "reasonably ok infrastructure" use-cases.
You might even be better off splitting battery powered devices
out at first as well.

(2) section 4, "Entities must be uniquely identified" is plain
wrong - 10.0.0.1 is just fine in lots of places. Other parts
of section 4 based on this error will likely also need
changing. (2nd paragraph for example.) Note that this is not
the same as objecting to 4.1, which is fine. Having
well-defined ways to identify things is fine but insisting
that all things are identified in any particular way (or ways)
is not. (7.4 and 8.1.4 have the same problem with their
combinations of "must" and "all".)

(3) 6.1, 6.2 and section 8 may have serious consequences - are
we really ready to go straight there? I think the
authorization implied by this is maybe too onerous to attempt
now except in limited cases (e.g. a data centre's separate
control VLAN). I don't believe saying "sufficiently
protected" is enough, as you do in section 9. Again an
applicability statement might help here limiting these
features to networks that are reasonably well managed.

(4) section 9, the relevant privacy protection needed here
relates to stored data. Transmitted data will require
confidentiality but stored data has serious privacy
consequences, especially for home network devices.

2013-03-04 06:26 Stephen Farrell

Ballot discuss text updated for Stephen Farrell

2013-03-03 10:40 Adrian Farrel

[Ballot comment]
Thank you for addressing my Discuss and for Sterling work on my Comments.

Looking at the diff I find the following points remaining...

---

> The term "power properties" is used in the Abstract and Introduction,
> and then shows up in Section 3.5. No clue is given as to what it means
> until Section 5.3; and then only definition by examples.
>
> Could you add it to the terminology section?

Your email said "yes"

---

> Shouldn't Section 4 expand on "subtended devices"? Or is this a forward
> pointer to Section 7?

No discusison in email, no change in text.

---

> I'm not sure, but it seemed to me that there is confusion between
> Secitons 5.2 and 5.3. 5.2 is supposed to describe the capabilities
> of the power interfaces, while 5.3 monitors what is happening at them.
>
> In some cases, the issue is simply not enough flexibility. For example,
> in 5.2.7 the "nominal voltage" on an interface may actually be a range.
> Consider devices that can be plugged into a varieties of supply and
> auto-detect.
>
> In some cases there seems to be direct overlap. For example, 5.2.5. says
> "The standard must provide means for monitoring for each Power Interface
> if it is in actual use." On the other hand, Section 5.2 seems to be
> missing an entry for nominal power ranges (especially maxima).

No discusison in email, no change in text.

---

> High/low power notifications in 5.3.6 are good. Did you consider high/
> low voltage and high/low frequency notifications?

No discusison in email, no change in text.

2013-03-03 10:40 Adrian Farrel

[Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss

Viewing the last 20 entries. Show full log.