|
| 1 | +# OpenADE Task Force Meeting 2026-03-11 |
| 2 | + |
| 3 | +## Agenda |
| 4 | +* Welcome |
| 5 | +* Introduction of attendees |
| 6 | +* Review and approve minutes |
| 7 | + |
| 8 | + |
| 9 | +## NAESB ESPI Standard Changes for ESPI Version 4.1 |
| 10 | +* SFTP has been removed as a transport option from the ESPI standard |
| 11 | + * The NAESB RMQ Executive Committee met March 4th and approved removal of the SFTP as a transport protocol from |
| 12 | + the NAESB ESPI standard. |
| 13 | +* NAESB Minor Corrections |
| 14 | + * Minor correction MC25009 to correct the ESPI Version 4.0 standard's inconsistency with how DEPRECATED elements |
| 15 | + are shown was approved by a simple majority of the NAESB RMQ Executive Committee on March 4th. |
| 16 | + * Minor correction MC26001 to correct ESPI Version 4.0 standard's Figure 2.0 to indicate the TimeConfiguration |
| 17 | + resource also inherits from IdentifiedObject |
| 18 | + * The requests (R25009 & R26001) are currently undergoing a 14-day [review and comment] |
| 19 | + * (https://www.naesb.org/retail_minor_corrections.asp) period until March 18th, 2026. |
| 20 | + |
| 21 | +## Additional NAESB ESPI Standard Changes |
| 22 | +* The next meeting of the NAESB RMQ Executive Committee will be held on October 22nd, 2026. |
| 23 | +* The following will be submitted to NAESB over the summer. |
| 24 | + * Simplify the ESPI Customer schema to reflect the same organization for Customer and IdentifiedObject as exist in |
| 25 | + the espi.xsd schema. |
| 26 | + * Refactor the ESPI standard to reflect elements that are actively supported by utilities. |
| 27 | + * Remove POST, PUT, and DELETE operations for Resource Servers from the ESPI standard. |
| 28 | + * Affects Section REQ.21.6.2.1 ESPI REST API Interface |
| 29 | + |
| 30 | +## Impact on CMD Certification |
| 31 | +* Changes to the CMD Certification Platform due to SFTP Protocol removal |
| 32 | + * All SFTP Function Blocks will be removed from the CMD Certification Platform |
| 33 | + * [FB_34] SFTP for Bulk (Energy Usage) |
| 34 | + * [FB_66] SFTP for Bulk (Retail Customer) |
| 35 | + |
| 36 | +## Open Discussion |
| 37 | +* URPX Utility Rate Plan Exchange Standard Update |
| 38 | + |
| 39 | +## Attendees |
| 40 | +* Donald F Coffin (Green Button Alliance) (Maintainer) |
| 41 | +* Jeremy J Roberts (Green Button Alliance) |
| 42 | +* Valdis Hellevik (Green Button Alliance) |
| 43 | +* Klaar de Schepper (Flux Tailor) |
| 44 | + |
| 45 | + |
| 46 | +## Minutes |
| 47 | + |
| 48 | +## Key takeaways |
| 49 | +- NAESB approval received to delete SFTP protocol transmission from Green Button standard version 4.1, currently in 14-day public review until March 18th |
| 50 | +- Two minor corrections approved for version 4.1: consistency in deprecated elements display and diagram updates for resource inheritance |
| 51 | +- Proposal submitted to simplify retail customer schema by removing unnecessary pass-through classes |
| 52 | +- Recommendation to remove POST, PUT, and DELETE operations from Green Button REST API, retaining only GET operations |
| 53 | +- Klaar presented URPX (Utility Rate Plan Exchange Standard), now an LF Energy standard, aiming for ISO certification |
| 54 | +- URPX seeks integration with Green Button for customer data and bill line items mapping |
| 55 | + |
| 56 | +## NAESB ESPI Standard Changes for ESPI Version 4.1 |
| 57 | +### Details |
| 58 | + - Donald: Request approved by RMQ Executive Committee last week, in 14-day public review until March 18th, publication expected in April as part of Green Button version 4.1 |
| 59 | + - Donald: Had 15-minute discussion in task force with someone using SFTP for EDI who misinterpreted the scope as removing SFTP across all standards |
| 60 | + - Jeremy J Roberts: Removal is timely as sandbox is being rebuilt from scratch, and implementing SFTP when nobody uses it is unnecessary extra work |
| 61 | + - Jeremy J Roberts: SFTP was never properly implemented by most parties, with security issues around shell access and dual authorization systems |
| 62 | + - Klaar: Removal makes sense for Green Button's argument against master key approach used in EDI |
| 63 | + - Donald: SFTP was included originally because one California IOU insisted on it, but it's designed for bulk monthly operations rather than interactive daily data requests |
| 64 | + |
| 65 | +### Conclusion |
| 66 | + - SFTP protocol removal approved and moving forward in version 4.1 |
| 67 | + - Two function blocks (FB34 and FB66) will be deleted from CMD platform as result |
| 68 | + Minor Corrections for Green Button Version 4.1 |
| 69 | + |
| 70 | + |
| 71 | +## Minor corrections approved for inclusion in the upcoming ESPI standard release. |
| 72 | + |
| 73 | +### Details |
| 74 | + - Donald: Minor correction 25009 addresses inconsistencies in how deprecated elements are displayed, with some showing strikethrough and others not |
| 75 | + - Donald: Correction also standardizes the representation of deprecated items, which had 2-3 different versions depending on editor and timing |
| 76 | + - Donald: Minor correction 26001 updates Figure 2 diagram to properly show resource inheritance from identified object, adding one block to right-hand column |
| 77 | + - Donald: All Green Button resources must inherit from identified object, requiring atom ID, rel links, published and updated tags as wrappers |
| 78 | + |
| 79 | +### Conclusion |
| 80 | + - Both corrections approved and will be included in version 4.1 publication |
| 81 | + Retail Customer Schema Simplification |
| 82 | + |
| 83 | +## A new request has been submitted to simplify the retail customer schema structure. |
| 84 | + |
| 85 | +### Details |
| 86 | + - Donald: Request assigned as R26003, will be included in version 4.2 due to insufficient time for version 4.1 |
| 87 | + - Donald: Simplification has no impact on output or data format, only affects programmatic representation in Java or Python applications |
| 88 | + - Donald: Original implementation by Marty lifted CIM model directly, creating unnecessary pass-through classes |
| 89 | + - Donald: Organizational role class provides no functionality, just passes through to customer and service supplier |
| 90 | + - Donald: Removing useless classes that were in CIM model for additional clarification and customization around documents and customer agreements |
| 91 | + |
| 92 | +### Conclusion |
| 93 | + - NAESB accepted the Request (R26003) for version 4.2 |
| 94 | + - Changes are cleanup and simplification only, no functional impact |
| 95 | + |
| 96 | +## Proposal to remove all CRUD operations except GET from the Green Button REST API interface. |
| 97 | + |
| 98 | +### Details |
| 99 | + - Donald: Proposes removing everything except GET from section REQ 21.6.2.1 Green Button REST API interfaces |
| 100 | + - Donald: Original rationale was utilities would post meter readings directly, but this has never happened in practice |
| 101 | + - Donald: Utility business structure uses back-end meter collection systems that translate raw data to database, then retrieve as Green Button format using only GETs |
| 102 | + - Donald: No utility has been certified for POST, PUT, or DELETE in 150+ certifications over the years |
| 103 | + - Donald: In today's security environment, allowing POST and PUT with string data could create significant security vulnerabilities |
| 104 | + - Klaar: Questioned reasoning, suggested it could be about reducing vendor risk and increasing adoption likelihood |
| 105 | + - Klaar: Proposed creating to-do task for future DER use cases and interoperability scenarios where PUT might be needed |
| 106 | + - Klaar: Suggested presenting removal with link to future investigation issue to address concerns |
| 107 | + - Donald: Acknowledged DER-oriented POST operation could be submitted as SEP but doubts it would pass NAESB Task Force |
| 108 | + - Donald: Referenced ongoing 2-year cybersecurity committee discussions about CVE notification requirements and liability transfer to vendors |
| 109 | + |
| 110 | +### Conclusion |
| 111 | + - Proposal to remove POST, PUT, DELETE operations moving forward |
| 112 | + - Possibility left open for future DER-specific API development |
| 113 | + - DELETE makes clear sense as no one would allow external parties to delete records |
| 114 | + |
| 115 | +## URPX Utility Rate Plan Exchange Standard Update |
| 116 | + |
| 117 | +### Details |
| 118 | + - Klaar: Presented comprehensive update on URPX standard development and goals for Green Button integration. |
| 119 | + - Klaar: Work began August 1st, approved by LF Energy on November 19th as Standards and Specifications standard |
| 120 | + - Klaar: Goal is ISO certification as international standard, will be W3C standard |
| 121 | + - Klaar: Covers rate plans, rate plan modifiers, structured eligibility rules, detailed pricing, time of use schedules, and traceability to official tariff documents |
| 122 | + - Klaar: Packages data currently scattered across tariff books, downloadable CSVs, addendums, and adjustment documents |
| 123 | + - Klaar: Provides single data stream for rate plan and customer situation to plug into cost modeling |
| 124 | + - Klaar: Based on OWL ontology with data instances in JSON-LD, following semantic web standards |
| 125 | + - Klaar: Will have documentation site and sandbox in future |
| 126 | + - Klaar: Seeking integration with Green Button pricing structure URI in customer schema |
| 127 | + - Klaar: Wants to map detailed price definitions to line items on bills for bridge between systems |
| 128 | + - Klaar: Vision is customers with Green Button integration can import parameters for customer profile to pull correct rate plan prices |
| 129 | + - Klaar: Bruce Nordman is OpenADR focus expert, Don Jackson connected to MATTER standard efforts |
| 130 | + - Klaar: Team includes Danny Schmidt from National Laboratory of the Rockies |
| 131 | + - Klaar: Currently in pre-draft mode, ontology not publicly accessible pending LF Energy IP review |
| 132 | + - Klaar: Materials under Apache 2.0 license, officially handed over from FluxTailor to LF Energy |
| 133 | + - Klaar: Meetings every 2 weeks to push forward more quickly |
| 134 | + - Klaar: Mapping to Green Button left out of current draft to avoid IP conflicts |
| 135 | + - Jeremy J. Roberts: Recalled previous utility bill representation phase two efforts and ideas for machine-readable line items |
| 136 | + - Donald: Welcomed update and collaboration opportunity |
| 137 | + |
| 138 | +### Conclusion |
| 139 | + - URPX moving forward as LF Energy standard with goal of ISO certification |
| 140 | + - Integration with Green Button planned for customer data and bill line items |
| 141 | + - Klaar will request access for Donald and Jeremy to pre-draft materials |
| 142 | + - Pilot project planned to demonstrate integration |
| 143 | + |
| 144 | +## Action items |
| 145 | +### Klaar |
| 146 | + - Request LF Energy permission to give Donald and Jeremy access to ERPEX pre-draft repository with draft mappings |
| 147 | + - Follow up on Green Button integration points for ERPEX, specifically pricing structure URI and bill line items mapping |
| 148 | + - Coordinate pilot project to demonstrate ERPEX and Green Button integration |
| 149 | +### Donald |
| 150 | + - Update meeting minutes with correct request number for retail customer schema simplification (R26003 or similar) |
| 151 | + - Monitor public review period for SFTP removal through March 18th |
| 152 | + - Consider submitting NAESB Request for DER-oriented POST operation with acknowledgment of future investigation |
| 153 | +### Jeremy J Roberts |
| 154 | + - Review previous Slack discussions about utility bill representation phase two and machine-readable line items structure |
| 155 | + - Continue sandbox rebuild without SFTP support |
| 156 | +### Task Force |
| 157 | + - Await Green Button version 4.1 publication, expected in April |
| 158 | + - Prepare for version 4.2 development cycle with retail customer schema simplification |
| 159 | + |
0 commit comments