Decision Proposal 018 - Administration End Points

[JamesMBligh]

Now that there are some established assumptions regarding the ACCC Register design the proposal for the administration end points has been produced.

The proposal is attached below and will be open for feedback until the 22nd May:
Decision Proposal 018 - Administration End Points.pdf

[c-j-hughes]

@JamesMBligh - can you confirm if the Administration End Points will be in scope for Phase 1, or will these be part of the scope for Phase 2? Capturing and aggregating the data outlined loosely in the proposal for #21 will take some engineering, and if this is a Phase 1 requirement it would be good to get some detail flowing. Thanks in advance.

[JamesMBligh]

Proposal has now been published.

-JB-

[anzbankau]

Hi James
The proposal refers to discoverability and not Admin, perhaps a copy paste error?

[JamesMBligh]

It looks like @anzbankau wins the award for spotting my deliberate mistake.

My bad. Thanks for spotting that. I've updated the document in the main comment.

-JB-

[NationalAustraliaBank]

NAB has the following feedback on this decision proposal for Administration end points.

Retrieve Statistics endpoint

1. With the API Standards and InfoSec streams merging, we assume that the unauthenticated InfoSec endpoints are excluded from this metrics reporting endpoint. Within the current CDS API suite, only the Product Reference APIs would fall into the unauthenticated tier.
2. As the metrics are relative to the time of query, for completeness of the response payload, can the payload include a date/time in which the metrics are referenced from?
3. Consistency in Array data type: Currently a mix of Array[Number] and Array[PositiveNumber].
4. The API structure follows well-defined / static structure. Do we foresee additional threshold tiers or metric types being introduced in the future, resulting in an API structure change. Was there any consideration towards a more flexible but loosely-defined API structure?
5. Historical TPS is described as 'average TPS' in this decision proposal. Decision Decision Proposal 021 - Non-functional Requirements #21 notes 'peak TPS'. Should this decision reflect peak TPS? With the current API structure, to support both metrics points at a later date would require a metrics API structure change.

Administration endpoint security

What will the design and requirements for the InfoSec profile for the administration endpoints look like? We seek further clarity on this, along with the definition of the Private to ACCC only security scope. Can Data61 provide any details based on the co-design activities that have been occurring between Data61 and the ACCC?

Administration endpoint NFRs

In reference to the NFRs in Decision #21, will there be any additional NFRs applied to the administration endpoints?

Metadata Cache Refresh endpoint

Without being able to holistically review the design of the ACCC Registry in conjunction with this endpoint, this decision proposal should be kept open or the Metadata Cache Refresh endpoint be separated from the Retrieve Statistics endpoint until a holistic review can occur.

We would also like to reiterate previous feedback related to dynamic registration: ConsumerDataStandardsAustralia/infosec#63 (comment).

[commbankoss]

It is our understanding that the ACCC will be providing an endpoint as a mechanism to 'Refresh' the meta data. It would be helpful for implementers if information on this was received ahead of locking down the Administration Endpoint requirements as it will be a subset of data that will need to be included as part of the registry.

Commonwealth Bank requires clarity on the security scope to be used for the administration end point. It is unclear from the documentation which security scope is to be used, or the mechanism by which ACCC user identity will be established.

In the documentation three concepts of time have been recommended, current, currentDay and previousDay. Given that there is only one object in the schema that requires current, TPS, we do not believe the administration endpoint needs to be real-time. Our understanding is that this meta data will only be retrieved 4-6 times a day by the ACCC. We would recommend factoring this into the Non Functional Requirements. Additionally, clarity is required on which time zone “currentDay” – and by implication previousDay – are defined in. Commonwealth Bank recommends that AEST be used.
Number of errors is defined in the commentary as “Number of calls resulting in error due to server execution over time”. It should be clear that this refers only to cancellation by the data holder, as we have no control of intermediate time-out configuration(s) present in the customer or data recipient systems or intermediate network elements.
Number of rejects is defined in the commentary as the number of calls rejected due to over-threshold. If a call is rejected due to over-threshold for traffic, we shouldn’t be including it in our metrics, as including it in our metrics would imply it was handled and thus not a reject. Additionally, implementing specific logging for rejected calls would create additional load when systems are under duress.

Lastly the documentation isn't clear on two of the objects. customerCount and recipientCount. As this is based on consent we would like to see it clearly stated that this will be only available on previousDay.

[JamesMBligh]

Thanks for the feedback. This is all very useful and will be reviewed and incorporated. I'll be closing down feedback on this thread. Any additional feedback or points of clarification can be posted on the current open thread for feedback (#67)

[JamesMBligh]

Please find attached the final decision covering this issue
Decision 018 - Administration End Points.pdf