Hi @TEF-RicardoSerr I havent been able to join the API backlog call.I will plan on joining the call on 27th of this month.
Are we waiting on additional supporting operators to take this API to TSC or anything else pending on this?

I wanted to ask a question based on what was presented in the API Backlog Meeting on October 24, 2024. Doesn't the scope of the feature(s) proposed fall in to Operate API?

Hi @gmuratk, IoT has been recognized as a family of APIs for CAMARA to support under GSMA Opengateway and this proposal provides basic set of capabilities for IoT device mgmt. This API will still falls in the category of northbound APIs as is the case for all CAMARA APIs. One uniqueness i like to note for this family of APIs is that rather than ASPs being the predominant users as in the case for other CAMARA APIs thus far, this API would be more widely used by enterprise customers (small/medium/large) in my opinion.
Focus of Operate APIs is quite different to what is proposed here. Operate APIs cater to standardizing the developer engagement and experience in terms of registration and accessing the APIs, inventory of the APIs, monitoring the utilizations, billing etc

Hope this helps.
would like to hear back on your thoughts and other's opinion as well on this.

Hi @maheshc01,
I have no arguments against IoT being in the scope. The reason I raised the question is mainly due to proposed capabilities.

IoT Provisioning APIs.pdf

@gmuratk The PR which has the slides i shared during the call is not approved yet. Reattaching it again here for reference.
the scope identified for the API in the proposal covers add, activate, suspend, restore, deactive and delete in the context of device mgmt.
Could you elaborate further on what you mean by these capabilities falling in the scope of operate APIs?

@maheshc01 thanks for sharing the slides. For example, capabilities for Adding devices and Activating service may have an overlap with service provisioning that is listed as part of 'Operate API' scope in CAMARA Project Charter.

@chenfr2-ChinaTelecom
Can you discuss possibly merging the scopes of #95 and #96 with this API proposal here in this issue? Thanks.

Hi , @maheshc01,
We proposed #95 (IoT SIM Status Mgmt) which is not only the management ability of device lifecycle management but also communication functions, and #96 (IoT SIM Fraud Prevention) which is mainly about the management of device-SIM card binding and regional restriction functions.

We had explored your proposal about Device Management and suppose that it is mainly focused on the lifecycle management of IoT SIM cards, which might be a small part of the device management in IoT, the scope of this proposal might covers a much wider range than your actual API capabilities.

So we suggest that perhaps you could change your proposal name to "Device LifeCycle Management"? Or our 3 proposals could form an new API family called “Device management”， and yours could be named as "Device Management - LifeCycle Mgmt", and our two proprosals could be named as "Device Management -- Communication Function Mgmt".