Line # Page # Section # Class Current content and comments
Page 13. Can we show an ‘Aggregator’ Customer as one of
Fig 2 the recipients of an OpenADR signal?
Page 13. What’s the red+orange/red+green concentric oval
Fig 2 shape indicating in that diagram? Is there any
significance to the color difference?
Page 19 Is the ‘Demand Response Provider’ role same as
‘DR aggregator’? The role ‘DR aggregator’ is
mentioned in various rows in the table, but not
line 510 Page 47 3.5.1 What’s the use case for FTP? If mentioning FTP,
should we mention SMTP (for email?)
lines 514, Page 47 the statement about “3rd party providers when
515 customers authorize their use of utility data” seems
to be more OpenADE specific than ADR. The
verbiage probably needs to be changed to reflect
the ‘control’ aspect of OpenADR.
Line 117 are we really addressing DER resources in version
1 of this doc?
Line 485 table 3.4.2 for Data elements: We probably need to
add “Randomization” flags – to control the ramp-in
and ramp-out during DR events. Similar to SEP 2.0
307 Replace Controlling Entity with Service Provider
312 Fig. 4 (Fig 1. Ssuggest merge LSE into Energy Service
2 in pdf) Provider.
312 Fig. 4 (Fig 2. Suggest add System/Market Operator to Figure 4
2 in pdf) as new swimlane and add process to initiate DR
Event for SMO.
378 Fig. 6 Include message for DR Event and Notify DR Event
312 Fig. 4 (Fig 3. Suggest we discuss if all the Business Processes
2 in pdf) shown in Section 3.2.1 are adequately represented
in Figure 4.
320 3.1 Suggest this LSE be thought of more as a Logical
Table of Component, and for purposes of this table we
Business combine with Energy Service Provider and remove
Roles LSE from the table and from Figure 4, overview of
business process flows.
All Label and index all tables in document.
350 I think Ed suggested this would be better named Dispatch
DR Objectives rather than Instructions. Also I wonder if
DR Direct Load Control should be under Dispatch DR
Instructions at all, since it is more in the nature of a
control command and probably should be under only DR
357 Operational Coordination should be raised one level in
outline. (Same bullet level as execute)
3.4 Some data objects listed here do not appear in Figure 6.
Also labels in Figure 6 are not same as Data Object
names in the list in this section.
Don't understand these requirerments
3.4.2 Where do we show whether this is a new event, updated
event, or cancelled event?
3.4.5 There is no separate section to Update or
Cancel/Retire, although there is a data element
called Report Type that covers this. Suggest put
report type in front matter before all the data
required for enrollment.
3.4.6 What is this? Should there also be a data element
State of called Report Type as there is for Resource to
Registrati indicate if this is an initial enrollment, update, or
3.4.4 Resource / Asset State
DR Assets Characteristics:
How do we define schedule? Where do we draw the
line on level of detail?
What is in place today?
Consider referencing Security Standards from OSG
3.5.3 Add step by step process diagrams to section for
Add Ed's comments
Update Figure 6. TS
Register of DR Program is Customer Enrollment
Enroll DR Asset / DR Resource (2 messages)
Add DR Event messags for Asset/Resource/DR Controlling
Change DR Signal to DR Event TS
Status / State
Remove Continuous Response (Is this a periodic
Add comment for on request or periodic report.
Suggest put report type in front matter before all the data TS
required for enrollment.
Explain that cloud signifies
communication transport, not the
whole network and roles or
Can we get a hold of the
No significance. Can add
explanation of what is in the
Get rid of colors?
Eliminate from indirect references
to DR Aggregator.
Add to Service Provider as an
Also in LSE defintion?
Use case is Secure FTP is
commonly implemented for
exchange of data files. Email is
outside the scope of the SRS.
Add RFC number.
Will eliminate 2nd sentence.
NIST Smartgid standards should
TS will look for skinnied list.
We should collaborate with
OSG security team on this.
Also look at section 3.3 for this.
Non-repudiation as part fo
Exludes injection of power and
Yes, but limited to those DER
devices that can affectd load
levels on the grid.
Added along with Duty Cycle,
Event Control (Randomizer),
Criticality Level, Device Class,
Current version maps to PAP09
Retail requirements as submitted
to NAESB EC.
(Old comment that shoud be
This was removed, but can't
remember the reason. It makes
sense to put it back in.
(Is this message same as DR
Event as defined, if not, is it in
Is it a special type of DR Event?
Would like input from current
Important touch point with
Match Figure 6 for message
Verified as same.
See first comment Figure 4.
Suggest that roles are aligned
with PAP09 list and combine as
part of logical components.
Remove Demand Response
DR Controlling Entity
Change swimlane in figure to
Add System & Market Operator
BB - In separate message for
3.4.3 , notify DR Event. Suggest
we combine into 1 message with
transaction and status elements.
TS - Planning vs. Execution must
be defined if combined.
Advance Notifiy has ability to
TS - Comment retracted.
Yes, and rename the element as
Yes, and be consistent with Asset