oneM2M Versioning Next Steps PRO-2017-0194 oneM2M Versioning Next Steps Group Name: PRO WG Source: Convida, Dale Seed, Bob Flynn Meeting Date: PRO#30.3, 2017-08-23 Agenda Item: Joint PRO/ARC

History of discussions Previous inputs for discussion and proposed solutions: ARC-2014-1592-REST_API_versioning (LAAS-CNRS), presented at TP#13 PRO-2014-0524-Versioning_Solution (Fujitsu), presented at PRO#13.2 PRO-2014-0597R02-CR_API_version_info (Fujitsu), noted at PRO#14.1 ARC-2017-006 / PRO-2016-0297(QCOM) discussed at ARC/PRO#26.1 PRO-2017-0028R01 (QCOM) discussed in joint ARC/PRO at TP#27 PRO-2017-0164 (QCOM) discussed at TP#30 PRO-2017-0188 (Convida) discussed at PRO#30.2 PRO-2017-0190 (QCOM) discussed at PRO#30.2

We have general consensus on... Add release version to <AE>, <remoteCSE> and <CSEBase> Registree indicates its supported release version in <AE> or <remoteCSE> Registrar CSE indicates its supported release version in <CSEBase> For unsuccessful registration due to release version mismatch, the Registrar sends a new RSC and should also include its supported release version in the Content parameter of the response

Still discussing ... Which attribute do we use for storing release version? Option #1 – A reserved key:value pair in the labels attribute Pros – Backwards compatibility is not an issue Cons – Release version information is a bit buried hence not as clean/easy to use Option #2 – A new attribute Pros – Dedicated attribute for versioning is cleaner/easier to use Cons – Backwards compatibility may be an issue (if not added to Rel-2A) Should we add version information in all resource types, not just <AE>, <remoteCSE> and <CSEBase>? Need to further discuss the use cases where this is needed to see if it is justified or not. If we use labels may be an easy decision. E.g. Creator is R2 and creates a resource that does not include newly added R3 attributes. An R3 AE wants discover only instances of this resource type that include support for the new R3 attributes.

Still discussing ... Include version information in request parameter? Option #1 – No Let Registrar CSE handle conversion of requests and responses that it forwards to / from each of its Registrees based on their release version Issue: Hosting CSE may support resource types that Registrar CSE does not. Registrar CSE may not be able to convert some requests and responses for its Registrees. See next slide for use case example. Option #2 – Yes Pros – Addresses issue identified above Cons: Adds extra overhead – This can be mitigated by adding the version parameter only when a CSE receives a request from one of its Registrees that needs forwarding over Mcc to a next hop CSE, and the release version of the Registree is less than the next hop CSE. The added version parameter is configured with the version of the Registree. Once added, the version parameter is kept in the request unless it is later forwarded to a next hop CSE having the same release version as configured in the version parameter. In this case the parameter is removed for backwards compatibility reasons (e.g. To prevent R2 CSEs from receiving this parameter)

Use case to consider AE1 R2 R2 IN-CSE R3 R3 MN-CSE1 R2 & R3 AE1 R2 R2 IN-CSE R3 R3 MN-CSE supportedResourceType does NOT include mgmtObj resource type IN-CSE supportedResourceType does include mgmtObj resource type RETRIEVE /~/IN-CSE/node1/mgmtObj1 RETRIEVE /~/IN-CSE/node1/mgmtObj1 R3 mgmtObj contains mgmtSchema attribute not supported in R2 OK [R3 mgmtObj] ! OK [R3 mgmtObj] MN-CSE cannot convert R3 mgmtObj to R2 before forwarding to AE1 ! R3 mgmtObj fails validation check for AE1 since it includes R3 mgmtSchema attribute

Use case to consider AE1 R2 R2 IN-CSE R3 R3 MN-CSE1 R2 & R3 AE1 R2 R2 IN-CSE R3 R3 MN-CSE supportedResourceType does NOT include mgmtObj resource type IN-CSE supportedResourceType does include mgmtObj resource type RETRIEVE /~/IN-CSE/node1/mgmtObj1 RETRIEVE /~/IN-CSE/node1/mgmtObj1 Version = R2 IN-CSE converts R3 mgmtObj to R2 for AE1 ! OK [R2 mgmtObj] OK [R2 mgmtObj] R2 mgmtObj does NOT contain R3 mgmtSchema attribute ! R3 mgmtObj passes validation check for AE1 since it does not include R3 mgmtSchema attribute