DSB Maintenance Iteration 8: Agenda & Meeting Notes (28 July 2021) - ConsumerDataStandardsAustralia/standards GitHub Wiki

DSB Maintenance Iteration 8 - Agenda & Meeting Notes (2021-07-28)

Date and time: 28/07/2021, 2pm - 3pm AEST
Location: WebEx
Dial-in details:

Chair: Mark Verstege, DSB
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 202

Agenda

Meeting notes

Introductions

This week is the second call of the 8th maintenance iteration. The purpose of the meeting is to review the open change requests and solution options.

  • Allow 5 min for participants to join
  • Housekeeping
  • Overview, purpose and intended outcomes of the meeting

Actions

  • DSB to add standards release structure as an agenda item for next meeting
  • CBA to propose practical solutions for addressing release candidates and future dated obligations
  • WBC to modify Issue #394 with a specific solution proposal
  • DSB to propose options for Issue 150

Release plan

  • v1.11.0 was published on June 30th 2021 incorporating CX standards changes and the approved change requests from the 7th maintenance iteration
  • v1.11.1: A hot fix release is planned for late July to address minor errata.
  • v1.12.0+: There is not v1.12.0 currently planned.

Open Decision Proposals

The following decision proposals are open for community feedback

DP # Closing date DP
206 Pending Decision Proposal 206 - Register Standards
203 No closing date Normative Standards Review (2021)
200 No closing date Noting Paper 200 - Action Initiation Framework
183 Closing today Decision Proposal 183 - Purpose Based Consents
182 30/07/2021 Decision Proposal 182 - InfoSec Uplift for Write
158 Closed Decision Proposal 158 - Participant capability discovery

Future Plan

Review of Q3 and new changes: https://github.com/ConsumerDataStandardsAustralia/future-plan/projects/1

Standards Release Process

In the previous meeting, we discussed enhancements to the release process for data standards. CBA to propose options.

A summary of the previous discussion:

  • A bank raised some issues with interpretation of standards releases
  • They asked whether the structure of the future dated obligations could be reviewed.
  • They proposed aligning future dated obligations to candidate releases. A release would then target a specific set of obligations on a specific date
  • Other banks were comfortable with the current structure of the future dated obligations
  • One participant explained they primarily want stability and predictability with timelines
  • Agreed that the DSB will create an agenda item for the next iteration meeting to discuss
  • Participants were asked to raise this issue as a set of practical proposals to progress discussion

Iteration 8 Change Requests

All open change requests can be found here: Standards Maintenance Issues.

Issues still under options development:

#150 - A loan may have no end date but loanEndDate is mandatory

See issue for solution options

#373 - Confusing use of the term 'base path'

#394 - Adding support for given names

#396 - Define new Digital Wallet Payee Type to relevant schemas

New change request. For discussion.

Normative Standards Review

Any other business

Address any other business arising from the community




Meeting Minutes

Notes

  • Standards Release Process

    • Discussed views from participants and key issues experienced:
      • Releases are not published at fixed intervals: they are published as needed. Bundling changes / themeing obligations before publishing may help
      • Timeframe between finishing the iteration and publishing changes is short: agree to increase the review window to consider staged changes with proposed obligations including an extra two weeks to the review cycle
      • Classify changes as "urgent" or "next candidate" vs "release in two versions time, i.e. n+2": This is already possible - the discussion at the end of the iteration focuses on when to make changes. This will be better integrated into the iteration process
      • Schedule any finalised changes into a release "bucket": this is currently done with the Banking Maintenance backlog but ways to improve visibility will be considered
      • Frequency of releases creates work for implementers: Identified that internal processes of some participants includes the review of all published changes then impact considerations after the release is made: Changes need to be made once they are taken to the Data Standards Chair for approval. This is in part driven by rules changes and the frequency cannot be fixed because of the various sources changes come in from. Instead, discussion considered identifying groups of changes and thematic releases. This is more manageable with the maintenance issues.

  • Issue 394

    • https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/394
    • Discussed scenarios how the existing first name / middle name fields can already support the change requested
    • Additional scenarios "C2 - compound first names with middle names" and "C3 - many given names are held by the DH as a single string and decomposition cannot be determined" were added
    • Participants to review and provide feedback ahead of the next meeting

  • Issue 150

    • https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/150
    • Discussed all options proposed
    • Option 2 is viable but less elegant
    • It was noted by participants that Option 3 is only breaking for DHs that have these issues
    • Could consider any breaking change to these affected endpoints in conjunction with ideation on other changes so there are more a substantive set of changes if the version of the endpoint was to increase

  • Issue 373

    • https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/373
    • Reviewed proposed changes - no issues raised
    • Discussed other terminology in the Consumer Data Standards vs CDR Register standards should be cleaned up
      • Brand vs Data Holder
      • Use of MTLS to sometimes mean mutually authenticated
      • Software Product vs Data Recipient
      • Action on the community to raise change requests for these terminology fixes

Other business

  • None

Next Steps

⚠️ **GitHub.com Fallback** ⚠️