-
Notifications
You must be signed in to change notification settings - Fork 56
DSB Maintenance Iteration 10: Agenda & Meeting Notes (02 March 2022)
Date and time: 02/03/2022, 2:00pm – 4:00pm AEDT
NOTE: meeting duration has been extended to 2 hours to accommodate Information Security, Register, Banking and Energy.
Location: WebEx
Dial-in details:
- https://treasuryau.webex.com/treasuryau/j.php?MTID=mf148de6a206fb95e1d25055ee9b7c90d
- Dial In Number: +61 2 9338 2221
- Dial In Access Code: 2653 293 7148
- Quick Dial: +61-2-9338-2221,,26532937148## Australia Toll
Chair: Ivan Hosgood, DSB
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 237
The Maintenance Iteration Calls are recorded for note taking purposes only. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material will be provided without the participant's consent. Participants may email [email protected] should they have any further questions or wish to have any material redacted from the record.
We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.
- Introductions
- Outstanding Actions
- Release plan
- Obligation Dates
- Maintenance / Release Process Changes
- Open Decision Proposals: key consultation dates
- Iteration 10 issues
- Any other business
Meeting notes
This week is the second call of the 10th maintenance iteration.
The purpose of the meeting is to prioritise and identify iteration candidates for the 10th maintenance iteration.
- Overview, purpose and intended outcomes of the meeting
- (Issue #428) [IN PROGRESS] DSB to confirm that the ACCC is updating the CTS to test the proposed wording, not the current wording
- DSB to propose a revised Obligation Milestone schedule incorporating existing obligation dates and community feedback. See Meeting Notes.
- DSB will work through Issue #464 to determine opportunities for improvement to address MI9 Retrospective.
- DSB to reach out to ADR contacts to assess priority of change for MI10 banking change requests #291 and #292.
- NAB to perform analysis on Issue #229 Service field in the Get Transaction Details API and advise on outcome in MI10 Meeting #2.
- Participant to post question on Zendesk regarding cdr_arrangement_jwt signing algorithm choice, this will be assigned to DSB who can consider whether existing articles provide answers and if not an article will be written or a change request initiated. - #482 raised to be addressed in this iteration
- Community to indicate priority by voting or commenting on CRs before MI10 Meeting #2 on 2 March 2022.
- Future releases currently being planned
- Based on the feedback, the DSB took an action propose dates incorporating feedback.
| Obligation Milestone | Original proposal | Updated proposal |
|---|---|---|
| Y22 #1 | 14th Mar 2022 | 31st Mar 2022 |
| Y22 #2 | 9th May 2022 | skip |
| Y22 #3 | 11th Jul 2022 | 4th Jul 2022 |
| Y22 #4 | 12th Sep 2022 | 31st Aug 2022 |
| Y22 #5 | 14th Nov 2022 | 1st Nov 2022 |
| Y23 #1 | 13th Mar 2023 | 7th Apr 2023 |
| Y23 #2 | 8th May 2023 | 8th May 2023 |
| Y23 #3 | 10th Jul 2023 | 10th Jul 2023 |
| Y23 #4 | 11th Sep 2023 | 11th Sep 2023 |
| Y23 #5 | 13th Nov 2023 | 13th Nov 2023 |
| Y24 #1 | - | 11th Mar 2024 |
| Y24 #2 | - | 13th May 2024 |
| Y24 #3 | - | 15th Jul 2024 |
| Y24 #4 | - | 9th Sep 2024 |
| Y24 #5 | - | 11th Nov 2024 |
- OAS 3.0 files will be published in parallel to OAS 2.0
The following decision proposals are open for community feedback
| DP # | Closing date | DP |
|---|---|---|
| 229 | Placeholder | Decision Proposal 229 - CDR Participant Representation |
| 225 | 18/02/2022 | Decision Proposal 225 - Data Recipient Security Standards |
| 211 | Pending | Decision Proposal 211 - Scope of Risk-based Authentication and Identity Proofing Framework, Threat and Attack Model |
| 210 | Pending | Decision Proposal 210 - Transition to FAPI 2.0 Profile |
| 203 | No closing date | Normative Standards Review (2021) |
All open change requests can be found here: Standards Maintenance Issues.
The standards maintenance backlog can be found here: Data Standards Maintenance
The following list of issues to focus on this maintenance has been finalised
The following change requests are currently in the design stage for this iteration
| # | Sector/Domain | Change Request |
|---|---|---|
| Issue 453 | Register | Consider an upper bound on trusting entity statuses when they go missing |
| Issue 482 | Register | JWT signing non-normative examples use unsupported signing algorithm |
| Issue 448 | Energy | EnergyPlanDiscounts contains optional fields that should be conditional |
| Issue 449 | Energy | EnergyPlanSolarFeedInTariff days field should be mandatory |
| Issue 457 | Energy | Energy - Get Service Point Detail register suffix should be optional |
The following change requests are targetted for this iteration
The following change requests have been proposed for this iteration. These will only be considered once iteration candidates have been addressed:
The following change requests have been deferred from maintenance iteration 10, to be considered for a future iteration
| # | Sector/Domain | Change Request |
|---|---|---|
| Issue 431 | Register | Register participant statuses do not detail data holder behaviour when ADR is revoked and SP inactive #431 |
- 1.16.1 is targeting an upgrade from Swagger to OAS3.0, this will not take advantage of new features available in the models. OAS3.0 specific features will be considered in future releases in consultation with industry.
- Based on the feedback DSB took an action and has further amended the proposed dates moving the 1st November to the 15th November 2022.
| Obligation Milestone | Original proposal | Updated proposal |
|---|---|---|
| Y22 #1 | 14th Mar 2022 | 31st Mar 2022 |
| Y22 #2 | 9th May 2022 | skip |
| Y22 #3 | 11th Jul 2022 | 4th Jul 2022 |
| Y22 #4 | 12th Sep 2022 | 31st Aug 2022 |
| Y22 #5 | 14th Nov 2022 | 15th Nov 2022 |
| Y23 #1 | 13th Mar 2023 | 7th Apr 2023 |
| Y23 #2 | 8th May 2023 | 8th May 2023 |
| Y23 #3 | 10th Jul 2023 | 10th Jul 2023 |
| Y23 #4 | 11th Sep 2023 | 11th Sep 2023 |
| Y23 #5 | 13th Nov 2023 | 13th Nov 2023 |
| Y24 #1 | - | 11th Mar 2024 |
| Y24 #2 | - | 13th May 2024 |
| Y24 #3 | - | 15th Jul 2024 |
| Y24 #4 | - | 9th Sep 2024 |
| Y24 #5 | - | 11th Nov 2024 |
- Design of Secondary Data Holder APIs is intended to be public with the exception of Information Security Profile. There are reports the swagger/OAS and other materials are not readily available to vendors and participants to assist in the development process.
- DSB to investigate copyright permissions and IP issues associated with development of SDH endpoints to ensure design of the APIs is publicly available.
-
Issue 453 Consider an upper bound on trusting entity statuses when they go missing
- Discussion covered the complexity of catering for the proposed options to keep track of date and time the attempts occurred.
- Proposal is to specify no upper bound.
- A precedence exists and the ticket has been updated to reflect this.
- Issue #453 Community input required to ensure the boundaries on this are correct.
-
Issue 482 JWT signing non-normative examples use unsupported signing algorithm
- The ticket has been updated with all of the relevant information.
- Issue #482 Community to review and provide feedback.
The following items are straightforward requests to change attributes, to either mandatory, optional or conditional.
- Issue 448 EnergyPlanDiscounts contains optional fields that should be conditional
- Issue 449 EnergyPlanSolarFeedInTariff days field should be mandatory |
- Issue 457 Energy - Get Service Point Detail register suffix should be optional
-
423
- A request to move demand charges object within other charges as demand charges for C&I customers are part of network charges
- The DSB suggests no change should be made as otherCharges already allows capturing network charges, which would include demand charges.
-
438
- DSB agreed to incorporate the changes proposed in this CR, specifically add 'adjustments' to 'otherCharges' in Energy Billing endpoints.
- DSB will then draft up structure to accommodate proposed changes for comment.
- Question was raised regarding the definition of 'Calculation Factor'. It is not currently defined and is assumed to be different to 'Distribution factor'
- It is not related to account details but it related to invoice detail.
- Clarification required on whether this is related to GST.
- Issue #438 A definition for Calculation Factor is required. Kingson EA to check and advise.
-
439
- A contract can contain different charges, but each of the charges could have different pricing models and time zones applied. This change request relates to moving the pricing model to be an attribute of the charge instead of the contract.
- Issue #439 DSB to propose solutions options to accommodate pricing models as an attribute of the charge instead of the contract.
-
472 This item triggered a number of discussions
-
DSB has proposed a change to Controlled Load rates.
-
Additional request to include start and end dates as similar fields to Energy plan tariff are needed
-
Feedback on the ticket is requested from community and rationale from EA.
-
Issue #472 Kingson EA to comment on the issue providing rationale to include start and end dates.
-
Enumeration values for days attribute within timeOfUse does not appear on standards but are present in swagger JSON files
-
DSB to create defect to fix missing ENUM in standards. Action has been completed refer to Issue #134 on Standards-Staging
-
DSB to consider alignment of definition for ENUM values for DAYS across sectors.
-
-
476
- Comparison sites would benefit from consistency if the same method to calculate interest rates was used for concessions.
- Issue #476 DSB will draft solution option for comments
-
477
- As AEMO does not appear on the register it's a challenge to make AEMO outages visible to ADRs. Current methods of communication between AEMO and Retailers deemed unsuitable for CDR.
- Discussion focussed on Retailers being able to merge AEMO outages with their own to make Shared Responsibility outages apparent to ADRs.
- Issue #477 DSB to propose a third Option for AEMO to publish outages via an API that can be consumed by retailers to incorporate AEMO outages with their own. Action completed, refer to comment
-
478
- Request from participants to elevate priority for this issue, more critical than 477.
- Issue #478 DSB has flagged #478 as potential candidate for this iteration and will add it to the Agenda for Meeting #3.
-
444
- DSB provided clarification that Issue 444 will cover discovery of data holders and associated PRD endpoint discovery. This is intended to be covered in MI #10.
-
465:
- ACCC provided feedback that there is a dependency on other API changes to determine whether the proposed date is appropriate. Issue 444 is a dependency that may impact this.
-
452
- There are two issues
-
Identify whether a Future Dated Obligation is appropriate if the register needs to be amended as a result of this CR.
-
coordination of testing, no one wants to test SSAs in production so the issue needs to be better understood
-
Consideration: the longer an old API is available the less flexibility there is to introduce change.
-
Concern was raised that the assumption that the GetSSA (V2) used by banking will not impact the banking participants needs confirmation. What authorisation scopes will be presented in V2 of the GetSSA call? If energy scopes are present, how comfortable are the current data holders that their solutions will be unaffected? Suggestions that data holders may reject the registration request. Clarification required on expected behaviour
- coordination of testing, no one wants to test SSAs in production so the issue needs to be better understood
-
Older APIs do need to be retired and a reasonable timeframe of 6 months from the introduction of the new API was suggested.
- Associated to this issue is the coordinated Energy testing effort and whether it will be dependent on this change occurring.
-
Guidance required with how to test the SSA (request and validate) because CTS does not cater for all interactions.
-
The ACCC has mock tools that can be used for development and testing so these should be considered before CTS.
-
Test coordination issues sit outside the remit of DSB and will be escalated to Treasury PMO.
- Issue #452 DSB to propose deprecation dates on each new Register API version
- Issue #452 DSB to model out scenarios for data holder behaviour when presented with unsupported authorisation scopes in the registration flows. This includes validating the assumption that Banking will not be impacted by the implementation of Energy.
- Issue #452 DSB to escalate the issue of testing coordination for energy and implication for industry to access ACCC tools to Treasury PMO.
-
459
-
ACCC published further clarification on their position on Github 28/02/2022: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/459#issuecomment-1053790045
-
Further discussion on what the future filtering of Register APIs might look like.
- Possibility was raised that authorisation scopes filtering could be coupled to the industry parameter.
- The benefit of such a change to the participants still remains in question. The default position remains that this change is not being considered for maintenance iteration #10. * Further input on this issue is welcome to help guide a position.
-
- Obligation dates. DSB to revisit proposed date of 1 November 2022 date and align with Energy milestones
- DSB to investigate copyright permissions and IP issues associated with development of AEMO endpoints to ensure design of the APIs is publicly available
- Issue #453 Proposal is to specify no upper bound. Community input is required to ensure the boundaries on this are correct. DSB to update the ticket
- [Issue #482] (https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/482) Community to review the ticket and provide feedback.
- Community to review and provide feedback on Energy CRs #448, #449 and #457
- Issue #438 A definition for Calculation Factor is required. Kingson EA to check and advise. DSB will then draft up structure to accommodate proposed changes for comment.
- Issue #439 DSB to propose solutions options to accommodate pricing models as an attribute of the charge instead of the contract.
- Issue #472 Kingson EA to comment on the issue providing rationale to include start and end dates.
- DSB to consider alignment of definition for BUSNESS DAYS and ENUM values for DAYS across sectors
- DSB to fix defect of missing ENUM in standards. Action has been completed refer to Issue #134 on Standards-Staging
- Issue #476 DSB to consider aligning methods to calculate energy concession rates with banking interest rates to standardise across sectors where possible.
- Issue #477 DSB to propose a third Option for AEMO to publish outages via an API that can be consumed by retailers to incorporate AEMO outages with their own. Action completed, refer to comment
- Issue #478 DSB has flagged #478 as potential candidate for this iteration and will add it to the Agenda for Meeting #3 in response to AEMO request as it is more critical than others currently in design.
- Issue #452 DSB to propose deprecation dates on each new Register API version
- Issue #452 DSB to model out scenarios for data holder behaviour when presented with unsupported authorisation scopes in the registration flows. This includes validating the assumption that Banking will not be impacted by the implementation of Energy.
- Issue #452 DSB to escalate the issue of testing coordination for energy and implication for industry to access ACCC tools to Treasury PMO.
None
MI10 Meeting 3 is the last planned collaboration session, DSB will then present solutions to each Change Request for peer review.