Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revise the Availability Requirements NFRs #660

Open
jimbasiq opened this issue Aug 21, 2024 · 4 comments
Open

Revise the Availability Requirements NFRs #660

jimbasiq opened this issue Aug 21, 2024 · 4 comments

Comments

@jimbasiq
Copy link

Description

Some recent planned outages from data holders have been days in duration. This is damaging to the success of the CDR, it is eroding trust and driving data recipients to alternative data sources such as screen scraping.

Intention and Value of Change

We need data recipients and consumers to be able to trust in the stability of the CDR framework. We need data holders to carefully consider the impact to their customers when planning outages to CDR services.

Area Affected

Availability Requirements

Change Proposed

The proposal is to make the Availability Requirements NFRs binding and applicable for planned and unplanned outages - https://consumerdatastandardsaustralia.github.io/standards/?diff#availability-requirements

The proposed change is to make the 99.5% up time target a MUST for planned and unplanned outages so that there is a clear definition of what is expected of Data Holders.

Any planned outage that will exceet this parameter should be discussed with the ACCC as an exception.

@jimbasiq jimbasiq changed the title [Descriptive Issue Title] Revise the Availability Requirements NFRs Aug 21, 2024
@JamesMBligh
Copy link
Contributor

I would like to voice support for this change. Since this issue was raised two weeks ago an energy retailer has published a 14 day planned outage. Clearly the current language is being taken advantage of.

It would be better to have the exclusion for planned outages to be removed from the definition of availability and then, if there is a real, justifiable, need for a prolonged outage a holder can discuss the need with the ACCC ahead of time to avoid any regulatory action.

@markskript
Copy link

markskript commented Sep 25, 2024

Skript would like to strongly support this change. In the past couple of months, one of the big four data holders has scheduled outages during business hours, severely affecting consumers' ability to operate as they rely on fresh data from the CDR to operate their day-to-day business operations.

To support this change, as of the 25/9/24 there are scheduled outages being published by DHs that clash with what we would deem normal operating hours (especially when taking the West-coast consumers into account)

  • One of the Big4 - a Tuesday 8pm-10pm AEST scheduled outage
  • Another Big4 - a full 10 hour scheduled outage starting at 8pm on a Thursday

@perlboy
Copy link

perlboy commented Sep 25, 2024

Agree in principle here although I wonder if it would be better to tie the CDR uptime to that of the primary digital channel. It seems reasonable to accept if a banks internet banking is down CDR probably can be as well. 2-4 hour scheduled outages on internet banking are still relatively common and if a Holder wants to decide their customers will tolerate it having CDR availability tied to that makes it no better or worse.

@joshuanicholson
Copy link

We want to add our support to this change.

We want to add some scope creep to this or a new CR around DH's reporting upcoming changes to their API endpoints/responses, which they believe MAY add a breaking change for an ADR. An example of this could be (but is not limited to)

  • including transactions id's to the transaction call where they were previously not disclosed
  • changing the format of how a date/time is reported
  • making the transaction detail call available where it was previously not available

Our worst fear as an ADR is for a change to be released that breaks our data collection or causes some form of data quality issue. While we appreciate the release of "fixes", any form of notice allows us to prepare and support consumers through the fixes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress: Design
Development

No branches or pull requests

6 participants