Decision Proposal 275 - Holistic Feedback on Telco Standards

[CDR-API-Stream]

The draft standards can be found on the official standards site.

Please note that only the endpoints and payloads are currently incorporated. In future standards releases changes will be made across the standards to include additional items specific to Telco such as the authorisation scopes, non-functional requirements and Consumer Experience data language.

Attached is a document outlining the feedback received in recent consultations and how it has been addressed in publishing these draft standards.
Decision Proposal 275 - Holistic Feedback Telco Standards.pdf

Feedback is requested from the community across the whole of the standards by all interested participants in this holistic consultation.

[kirkycdr]

Please note type and billingType are missing from getAccountDetail. This will be fixed in the next update to the OAS.

[AmeliaMetcalf]

Product Types

The proposal now suggests updating product types from ‘Mobile and Broadband’ to ‘Mobile and Internet’.

In our view, this update does not provide any additional clarity. The two terms do not sit at an equivalent hierarchical level. ‘Mobile’ can (and usually does) provide internet connectivity. ‘Mobile’ can be data-only or voice and data. Internet could also be data-only, or voice and data.

It would be useful if the DSB could provide advice on the intended outcome. If the intended outcome is to identify how the service is utilised, then one option could be to specify ‘data’, or ‘voice and data’.

[AmeliaMetcalf]

Network Subtypes

The proposal notes DSB is evaluating whether specifying access network types for products will be beneficial. In our view, there is no real value in specifying access network types, as these can change during the life of the service. For example, an internet customer may move from FTTN to FTTP.

Industry does not define the network subtype for mobile customers as this can change constantly depending on what radio access technologies are available – for example, a customer may switch between 3G, 4G and 5G depending on location.
 

[AmeliaMetcalf]

Service ID’s

NBN services should always be identified using the ‘Access Virtual Circuit Identifier’. This is a unique 15-digit number that represents the NBN Access Virtual Circuit, which identifies the unique Customer service.

This is consistent with arrangements in the Industry Code C647, which describes the processes between customers, retail service providers (RSPs), access seekers and access providers for the post-migration transfer of fibre access services over the NBN and seeks to minimise customer impacts during the transfer of an active NBN service between Retail Service Providers (RSPs).

Mobile services should be identified using the 10-digit mobile number.
 

[AmeliaMetcalf]

Sector name as ‘telco’

We have no concerns with the sector name being ‘telco’.

[AmeliaMetcalf]

Account Concessions
 
It is not clear what ‘account concessions’ means or what it is meant to capture. Further guidance from DSB on this category would be useful.

[AmeliaMetcalf]

Invoice data

Further to the above comment in ‘Account payment schedule’ about prepaid mobile services - prepaid services have no account payment schedule, and therefore no invoice data. Further guidance from DSB on whether these accounts should be captured – and, if so, how - would be welcomed.

[AmeliaMetcalf]

Billing Type

The proposal says ‘as suggested and a new type “UPFRONT_PAID” for subscription style services’.

It is unclear what is meant by this, or what it is intended to capture. If it is intended to capture pre-paid mobile services, then these are not typically classified as subscription services, because there is no ongoing commitment and some forms of post-paid are subscriptions paid in advance. Further clarification from DSB would be useful.

[AmeliaMetcalf]

Authorised Contacts

The proposal notes DSB is awaiting confirmation on whether authorised contacts will be required in the standards. Our view is that authorised contacts are relevant, and we strongly support including authorised contacts in the telco standards.

[AmeliaMetcalf]

Accounts/Services with no Invoices

The proposal notes that some accounts and services do not have invoices, but questions if such services have an account identifier.

Our advice from industry is that some prepaid accounts will have an account number, but others do not. We agree with the approach proposed by DSB.

[AmeliaMetcalf]

Voucher Top-ups

The proposal notes a new type has been added to the payment method to include vouchers. We agree with this approach.

[AmeliaMetcalf]

Account Level versus Services Level Balances and Usage

The proposal questions whether to provide only account level usage and balances for some types of
accounts where service level data is not available.

Our response is that usage data will not always be available. Not all services will have real-time billing data to provide usage and balance, and some charges may be reliant upon third parties to provide data which may not come in from other sources for some time - for example, international roaming.

[AmeliaMetcalf]

Below is the consolidated submission from Communications Alliance. The individual elements of the submission have been set out as comments for response above.

20221128_Communications Alliance_Submimssion on CDR telco standards FINAL.pdf

[mraineyoptus]

Please see comments/queries in the attached from Optus.

Decision.Proposal.275.-.Holistic.Feedback.Telco.Standards with feedback.pdf

[CDR-API-Stream]

Product Types

The proposal now suggests updating product types from ‘Mobile and Broadband’ to ‘Mobile and Internet’.

In our view, this update does not provide any additional clarity. The two terms do not sit at an equivalent hierarchical level. ‘Mobile’ can (and usually does) provide internet connectivity. ‘Mobile’ can be data-only or voice and data. Internet could also be data-only, or voice and data.

It would be useful if the DSB could provide advice on the intended outcome. If the intended outcome is to identify how the service is utilised, then one option could be to specify ‘data’, or ‘voice and data’.

For reference, these were originally based on Schedule 5 (Part 1.2 Interpretation) in the proposed rules.
See:

• Fixed internet Service
• Public Mobile Telecommunications Services (TCA 1997)
• Relevant product

They are also common search types in product comparison websites e.g Mobile Plan / Broadband comparison. Your suggestion is noted and any further feedback is welcomed.

[CDR-API-Stream]

Network Subtypes

The proposal notes DSB is evaluating whether specifying access network types for products will be beneficial. In our view, there is no real value in specifying access network types, as these can change during the life of the service. For example, an internet customer may move from FTTN to FTTP.

Industry does not define the network subtype for mobile customers as this can change constantly depending on what radio access technologies are available – for example, a customer may switch between 3G, 4G and 5G depending on location.

Thanks for the feedback. This was part of feedback in DP 262 and 265

DSB is also questioning if this is beneficial. It may be useful from a product comparison perspective. Further feedback is welcome.

[CDR-API-Stream]

Service ID’s

NBN services should always be identified using the ‘Access Virtual Circuit Identifier’. This is a unique 15-digit number that represents the NBN Access Virtual Circuit, which identifies the unique Customer service.

This is consistent with arrangements in the Industry Code C647, which describes the processes between customers, retail service providers (RSPs), access seekers and access providers for the post-migration transfer of fibre access services over the NBN and seeks to minimise customer impacts during the transfer of an active NBN service between Retail Service Providers (RSPs).

Mobile services should be identified using the 10-digit mobile number.

This is a great suggestion and will reference this in the draft standards wrt NBN services.

[CDR-API-Stream]

Sector name as ‘telco’

We have no concerns with the sector name being ‘telco’.

Thanks. Noted.

[CDR-API-Stream]

Authorised Contacts

The proposal notes DSB is awaiting confirmation on whether authorised contacts will be required in the standards. Our view is that authorised contacts are relevant, and we strongly support including authorised contacts in the telco standards.

Thanks. We will be leaving authorised contacts in the draft standards until further notice. They currently are optional.

[CDR-API-Stream]

Account Concessions   It is not clear what ‘account concessions’ means or what it is meant to capture. Further guidance from DSB on this category would be useful.

Concessions (rebates and grants) are included Schedule 5 (Part 1.3 Meaning of terms for types of data) (2) (b) (iv) Account in the proposed rules.

Any industry examples of these would be useful as discussed in DP 263

[CDR-API-Stream]

Invoice data

Further to the above comment in ‘Account payment schedule’ about prepaid mobile services - prepaid services have no account payment schedule, and therefore no invoice data. Further guidance from DSB on whether these accounts should be captured – and, if so, how - would be welcomed.

[CDR-API-Stream]

Wrt to accounts with no invoices. Some guidance was provided on this on DP275. In such instances, it would be
expected the Invoice API would return an error. For example 404 - Unavailable Account which
has been included in the API specification for the CDR. Please also refer to the standards error
codes.

[CDR-API-Stream]

Billing Type

The proposal says ‘as suggested and a new type “UPFRONT_PAID” for subscription style services’.

It is unclear what is meant by this, or what it is intended to capture. If it is intended to capture pre-paid mobile services, then these are not typically classified as subscription services, because there is no ongoing commitment and some forms of post-paid are subscriptions paid in advance. Further clarification from DSB would be useful.

This was added from feedback received on DP 262 and DP 256

For Upfront subscription services and hybrid services e.g paid in advance and usage assessed at the end of a set period.

If the terminology is unclear, happy to consider suggestions. Will look to also update the description of this enum.

[CDR-API-Stream]

Voucher Top-ups

The proposal notes a new type has been added to the payment method to include vouchers. We agree with this approach.

Noted

[CDR-API-Stream]

Account Level versus Services Level Balances and Usage

The proposal questions whether to provide only account level usage and balances for some types of accounts where service level data is not available.

Our response is that usage data will not always be available. Not all services will have real-time billing data to provide usage and balance, and some charges may be reliant upon third parties to provide data which may not come in from other sources for some time - for example, international roaming.

Great feedback. Noted this highlights the currency of usage and balances data.

[CDR-API-Stream]

Please see comments/queries in the attached from Optus.

Decision.Proposal.275.-.Holistic.Feedback.Telco.Standards with feedback.pdf

Thanks for your feedback. I have summarised your comments from the PDF in the points below.

• Product Types. Please refer response Decision Proposal 275 - Holistic Feedback on Telco Standards #275 (comment)
• Network Sub Types. Please refer Decision Proposal 275 - Holistic Feedback on Telco Standards #275 (comment)
• Service ID's Decision Proposal 275 - Holistic Feedback on Telco Standards #275 (comment)
• Payment Schedules. Noted. For adhoc payments for pre paid services. The payment would be captured under account transactions. For prepaid services where there are scheduled topup payments or triggered payment events such as a balance thresholds these may be able to be captured as payments in the paymentScheduleUType. Further feedback would be helpful.
• Concessions. Correct at Federal and state level. Will look to provide more specific examples. Can you provide details on the RSP discount your referring too? Please also refer Decision Proposal 275 - Holistic Feedback on Telco Standards #275 (comment)
• Endpoints. Thanks. Telco endpoints are intended to be specific to Telco, with commonality across the CDR a design principle as documented in the noting paper. Banking endpoints differ significantly from Telco. We have been through a 3 month consultation on the Telco Endpoints. Please refer 256. 262, 263, 264, 265, 266
• Customer Data. Wrt Customer Data are you able to detail anything specific to telco in describing any customer data that is not covered in DP 257
• Balance and Usage: Please refer DP266
• Incentives and Discounts: This refers to product data payloads. Please refer DP 262
• Minimum and Maximum Values. These refer to min and max charges on a plan. https://consumerdatastandardsaustralia.github.io/standards/#get-telco-account-detail
• Rebates. Rebates have been considered a "type" of concession. Please confirm if this is not correct. https://consumerdatastandardsaustralia.github.io/standards/#tocStelcoconcession
• Authorised Contacts: Noted
• paymentStatus is described as "Indicator of the payment status for the invoice" which is either PAID, PARTIALLY_PAID or NOT PAID. Please provide more clarity to the question if this is unclear https://consumerdatastandardsaustralia.github.io/standards/#tocStelcoinvoice
• Other charges. They are optional. You are correct that further descriptions of the ENUM values would be helpful. They were intended to be indicative to guide consumers on charges that were not part of their plan.
• Transaction Type. Other as the transaction type is to identify other types of charges such as a service call out and once off charges. This is indicative, welcome to feedback on an indicate list of types
• Vouchers. Noted
• Account level vs. Service Level Usage. Conditionality is included in the proposal. Please refer DP266 for supported, unlimited, limited and unsupported features

[CDR-API-Stream]

An update to the Draft Telco Standards has been published. This mostly includes errata and minor fixes. We will be leaving DP 275 Holistic feedback open until further notice for further feedback..

Merry xmas!!

[CDR-API-Stream]

In addition to the updates posted just prior to Christmas we intend to post a patch release to the draft telco standards in the coming weeks. A list of fixes to date is posted below. If anyone has any further feedback on this DP please post your updates or reply in the threads. For consideration to be included in the patch update.

• Updated Product List default to ALL
• Added reusable "headers" in OAS "components"
• Removed unrequired paging query parameters
• Added missing "updated-since" query parameter
• Minor typos in descriptions
• Removed paginated response object for non-paginated API.
• Added missing paginated response object to paginated API's
• Minor updates to TelcoProduct/ TelcoContract

[c799878]

A Service ID in CDR cannot be a "10-digit mobile number" (04xxxxxxxx) as -- by the ID Permanence rules -- it has to be "entirely arbitrary and have no inherent meaning", and "MUST NOT be transferable across Data Recipient Software Products" etc.
A Service ID presumably cannot be an Access Virtual Circuit Identifier for the same reasons.

And mobile numbers should be +614xxxxxxxx in standards, not 04xxxxxxxx.

[CDR-API-Stream]

A Service ID in CDR cannot be a "10-digit mobile number" (04xxxxxxxx) as -- by the ID Permanence rules -- it has to be "entirely arbitrary and have no inherent meaning", and "MUST NOT be transferable across Data Recipient Software Products" etc. A Service ID presumably cannot be an Access Virtual Circuit Identifier for the same reasons.

And mobile numbers should be +614xxxxxxxx in standards, not 04xxxxxxxx.

Thanks for the message James. The serviceId is only returned from the data holder adhering to ID Permanence as you mention, via the Get Accounts or Get Account Detail. ID Permanence states:

If an ID is specified the ID value MUST be entirely arbitrary and have no inherent meaning. For instance, an ID should not be a combination of other fields or a string that can be parsed to extract meaningful information

The API must not except an identifier such +61xx 04xx that does not adhere to permanence rules. The description represents what servicesId's a Telco DH could be using internally we do not mandate a specific type except what is returned adheres to ID Permanence. To access Account data a consumer needs to authenticate/ consent.

[CDR-API-Stream]

Closing this issue with 1.22.1 release. An updated feedback thread will be opened shortly