Hi folks, sorry about the delay. I finally had a chance to get caught up and go over the latest draft.
I identified two issues we may need to discuss and several editorial challenges (Noted below)
Issues:
Ln 369 we discuss intelligent distribution elements up to an intelligent transformer, but don’t define the lower bound; since we’re discussing scope it seems we need a better definition here (to what lower end might we go – the proverbial “smart toaster”?); or simply the ESI (or some lower level component that we want to provide or describe examples of such)?
Use of PartyID-CounterPartyID – why do we need both in a single payload? Wouldn’t a given party know what its own ID is? So in the context of any given interaction we simply need to know the partyID of the other party? If we respond to something from a party, do we not simply pass our partyID to the counterparty since they know who they are, they just need to confirm who we are? (in addition to the other transaction identifying information?)
The analogy is Bob and John have a conversation:
Hi Bob, this is John, how are you today?
Hi John, this is Bob, I am fine. (Duh – I know you are Bob, I just asked you a question and identified you in the process. Assuming there is some sort of discovery process I already know he is and why I had his identification before I even talked to him)
Editorial challenges:
Ln 9 – capitalization “smart grid”
Ln 19 add comman “volatile surpluses,”
Ln 21 comma placement
Ln 33 remove comma after “supply and demand”
Ln 286 strike the word “in”
Ln 333 strike the period at the end of the line (make bullets consistent)
Ln 351 colon at end of the line?
Second, as we have seen, each VEN can implement the VTN interface for another interaction. 629
Third, the pattern is recursive as we showed (shown) above in Figure 3-3 and allows for more complex structures.5
Ln 659 capitalization “AN”
Lin 712 – 715 periods at the end of bullets (remove for consistency)
Table 4-5 remove period after “ramp up period”
Ln 1004 Dramatis Personae – strike this
Table 5-17 believe “Derived” is referring to “Usage” not “sage”
Ln 1356-1357 Party-counter-Party naming is not consistent with use earlier in the spec
Ln 1442 strike the comma Tenders or Events
Table 7-2, 7-3, 8-2, 12-1 shouldn’t this be Party-CounterParty?
Change 1662-1663 Change to : An event is the core Demand Response information structure, so the exploration of this concept will begin with the UML diagrams for the EiEvent class and for each of the operation payloads.
Table 10-1 consistent capitalization of operation names
Figure 10-3 Report services have an Update/Updated naming (deprecated). Should be Change/Changed to be consistent with the naming conventions specified earlier in the document.
Ln 1885 strike the word “once”
Ln 1913 Change “In this section, we describe the enterprise software approach to security and composition as applied to this Energy Interoperation specification.”
To: “In this section the enterprise software approach to security and composition as applied to this Energy Interoperation specification is described.”
Ln 1920 the hyphen should be a semi-colon
Ln 1926 Change to : (This figure is repeated and relabeled)
Ln 1929 Change to: In this example a specific reliability DREvent initiated by an Independent System Operator is modeled.
Ln 1937 Change “our” to “the”
Ln 1962 Change to: Store L also has a relationship with aggregator E, which for this example is Store L’s local utility
Ln 1969 Change to: So for a simple Demand Response event distribution, there are potentially four different security profiles
Ln 1977 Change to: In the rich ecosystem of service and applications in use today, applications are (loosely) assembled or composed rather than crafted as one large thing.
Ln 1884 – 1885 Change to: Rather than creating a single application that does everything, perhaps in its own specific way, components of code, of standards, and of protocols can be used to achieve the same goal.
Ln 1995 – 1996 Change to: In this section some specific technologies and standards in the palette for building a secure and reliable implementation of Energy Interoperation are described
Ln 2030 – 2031 Change to: The Energy Interoperation services required as part of the OpenADR Profile are presented in a simplified tabular form..
Ln 2038 – 2039 Change to: The Energy Interoperation services required as part of the TEMIX Profile are presented in a simplified tabular form
Ln 2047 – 2048 The Energy Interoperation services required as part of the Price Distribution Profile are presented in a simplified tabular form
Ln 2055 – 2056 Change to: Four conformance points for Energy Interoperation 1.0, modified by the networking technology 2055 used are defined.
Cheers -
Gerald R. Gray, PhD
Sr. Project Manager
Enterprise Architecture | Utility Enterprise Integration
Power Delivery and Utilization
cell: 865.582.6039 | office: 865.218.8113