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

Clarity around GET Metrics for AER, DELWP and AEMO #515

Closed
CDR-API-Stream opened this issue May 24, 2022 · 1 comment
Closed

Clarity around GET Metrics for AER, DELWP and AEMO #515

CDR-API-Stream opened this issue May 24, 2022 · 1 comment
Labels

Comments

@CDR-API-Stream
Copy link
Collaborator

Description

In discussion with Treasury and the ACCC it has been recommended that the standards make it clear that AER and DELWP (for Energy Tariff Data) and AEMO (as secondary data holder for a number of data clusters) will not be required to implement the GET Metrics endpoint.

Area Affected

This would be a change to the description of the GET Metrics API

Change Proposed

A statement indicating that the three agencies identified (using language that aligns to their identification in the rules) will be explicitly exempt from implement the GET Metrics API

@perlboy
Copy link

perlboy commented May 25, 2022

While it is the governments prerogative as to whether related government entities are required to provide Get Metrics data, as noted in the MI call the absence of this data, particularly for designated secondary holders (ie. AEMO), will make dispute resolution with respect to a Data Holders recorded metrics difficult.

Assurances may be given that these departments are tracking metrics via alternate means but I'd note that a correct, like for like, implementation of the current Get Metrics endpoint is a complex undertaking including 95th percentile, microsecond resolution and per minute aggregation recommendations. I'd also note that if instrumenting to achieve these is already delivered attaching an API to it is a somewhat trivial task (ie. the work effort isn't the API it's the data to populate the API).

Under these circumstances it seems reasonable that, in the absence of mathematically similar (and preferably non-opaque) collection of data from an SDH, a Holder can directly dispute assertions provided by that SDH as to their supposed performance and dispute a potential accusation from the Regulator with respect to NFR non-compliance.

Put more bluntly, the Regulator may make a rather vicarious legal assertion related to Holder NFR non-compliance with nothing more than the hear-say of other participants.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

3 participants