Skip to content

DSB Maintenance Iteration 19: Minutes (17 April 2024)

Jump to bottom
CDR API Stream edited this page Apr 30, 2024 · 1 revision

Meeting Minutes

Housekeeping

Planned changes to how maintenance iteration meetings are run:

  • We have considered a number of things to manage the workload in a maintenance iteration.
  • When a significant number of issues are tabled for discussion, we'll remove the 5-minute delay on commencement of the call to increase discussion time.
    • Discussion on each issue will be timed and if the discussion can't be concluded within the allotted time, we'll take it offline.
    • If all issues have concluded and time remains, we can revisit those issues.
  • Start times for each domain will be estimated and advertised when the agenda is published.
  • This is a trial for Maintenance Iteration 19 in the hope it helps ensure we cover the breadth of issues in the Standards and we can adequately progress a sufficient number of issues per iteration.

Release Plan

  • Comments made on Energy issues after Decision Proposal 340 had been sent to the Chair for approval were discussed.
    • On review, most of the questions raised in the comments had been addressed in the staged changes, with the exception of a minor amendment of additional ENUM values. Comments on issues now explained #624, #625 and #627.
    • Retailers/Data Holders confirmed during the call, that the addition of ENUM values can be accommodated.
    • With agreement from attendees, the amendments were incorporated into the Decision Proposal and resent to the Chair.
    • Changes arising from MI18 will be published in v1.30.0 in the coming days.

Requirements Analysis

Common

Security

Maintenance Iteration 19 Backlog Grooming

Holistic Changes

Candidates

CX

Security

  • None proposed

Register

Banking

  • #636 Remove BankingTransactionDetail and incorporate extendedData into BankingTransaction
    • The discussion on this thread is excellent.
    • Intention of change is to provide a history of a consumer's interaction with a Data Holder where the payer and payee information associated to a transaction would add considerable value to platform capability.
    • The concern associated to obtaining this information, using current structure of APIs and Schemas, is the amount of traffic it will generate.
    • A new consumer taking up services offered by a platform highlights a problem when TPS and traffic limitations need to be adhered to.
    • Anticipated growth in these calls could jump from 5 - 8 API calls now to hundreds even thousands for an individual consumer. This doesn't seem good for Data Holders.
    • There is overlap with issues under consideration by the NFR Consultative Group and DP 338. It would be worth prioritising this issue along with all others considered in 338.
    • Agreed to include this issue as a candidate to discuss requirements over the next few meetings.

Energy

  • None proposed

Telco

  • None proposed

Common+Admin

  • None proposed

Schema

  • None proposed

Errors

  • None proposed

NFRs

  • None proposed

Operational

  • None proposed

Documentation

  • None proposed

Other business

  • Skript indicated a Banking change request was imminent and, like 636, overlaps with items on the agenda for the NFR Consultative Group.
  • ACTION: DSB to continue reviewing the backlog.

Next Steps

The DSB invites the community to propose items for consideration in this MI by posting requests on Decision Proposal 347 - Maintenance Iteration 19

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally