Meeting minutes: MoM-2024-01-30.md

[jlurien]

What type of PR is this?

• documentation

What this PR does / why we need it:

Agenda for next meeting. to be updated with minutes

[jlurien]

@bigludo7 Please review the meeting minutes. If you need some clarification as you were not in this one, let me know. Thanks

[bigludo7]

@jlurien for #141 not sure why waiting for Commonalities outputs.
The guidelines stated: For this specific event, the data must feature terminationReason attribute.

There is not specification of the value enumeration and with the diversity of the APIs not sure it makes sense . For me I'm afraid that going to Commonalities will take unnecessary delay for a very short point - WDYT?

[jlurien]

@jlurien for #141 not sure why waiting for Commonalities outputs. The guidelines stated: For this specific event, the data must feature terminationReason attribute.

There is not specification of the value enumeration and with the diversity of the APIs not sure it makes sense . For me I'm afraid that going to Commonalities will take unnecessary delay for a very short point - WDYT?

The question is about whether we should agree on the value for terminationReason across APIs, as I think that this case will happen for all APIs with subscriptions.

In QoD there is PR proposal that is somehow similar, to add a new reason for termination, even if in QoD there are no explicit subscriptions, and notifications are implicit to the QoS session, and there the reason value for this case is

    * `DELETE_REQUESTED`- User requested the deletion of the session before the requested duration expired

They also have NETWORK_TERMINATED as another reason.

For Geofencing I see SUBSCRIPTION_DELETED acceptable as well, but other APIs with subscriptions may decide on another value if it is not documented in Commonalities.