Different planes for the resource structure Group Name: WG5 – MAS and WG2 – ARC Source: Nicolas Damour, Sierra Wireless Meeting Date: Agenda Item: tbd

Problem statement 1/2 Management objects have been defined as a resource type that can be “instantiated” into firmware, memory, etc. Yet these different “instances” have some common attributes (mgmtDefinition, objectID, objectPath, description) and some specific attributes => are we not looking in reality at different resource types sharing some common attributes?

Problem statement 2/2 We want to make some resources manageable through DM technologies: cmdhPolicy, statsConfig => we make them “instances” Some resources may be managed by DM technologies or not: schedule, locationPolicy? => do we also make them “instance”? Answer: NO, we only need the attributes!

Proposal - Theory The “core” resource structure represents the Service Plane of oneM2M and the core CSFs: – Addressing, Identification and Registration – Discovery – Data Management & Repository – Subscription & Notification – Group Management – Communication Management & Delivery Handling – Location – Network Service Exposure

Proposal - Theory Other planes constitute the “enabler CSFs”: – The Security Plane (Security CSF) injects the common attributes it needs (accessControlPolicyID) onto the resources it will affect (currently: all!) – The Management Plane (Management CSF) injects the attributes it needs (mgmtDefinition, objectID, objectPath, description) onto the resources it will affect (i.e. for which DM technology is used) – The Charging Plane (Service Charging and Accounting CSF) may inject attributes onto resources for the purpose of collecting statistics when these resources are used.

Proposal - Practice The common attributes should comprise: – General purpose attributes: resourceType, parentID, creationTime, expirationTime, lastModifiedTime, versionTag, labels, creator, link, announceTo, announcedAttribute – “Injected” Security Enabler attributes: accessControlPolicyID – “Injected” Management Enabler attributes: mgmtDefinition, mgmtObjectID, mgmtObjectPath, mgmtDescription To solve our problem, any resource that needs to be managed through an external DM technology will have these attributes defined

Proposal – In Detail 1/4 Split the section into: – – Common general purpose attributes – – Common security attributes – – Common management attributes In the section , introduce the four renamed common attributes mgmtDefinition, mgmtObjectID, mgmtObjectPath and mgmtDescription Into the same section , introduce the “mgmtObj resource prototype” (“class” or “interface” were intentionally disregarded), and move all of the content of the current section on mgmtObj into here

Proposal – In Detail 2/4 Proposal for a text describing the mgmtObj resource prototype: “Any resource of any type can, in addition to the attributes defined by its resource type, optionally bear the four management attributes defined above (either none or all of the four). In that case, that resource will belong to the mgmtObj resource prototype in addition to its regular resource type. The mgmtObj resource prototype represents a general structure to map to external management technology (e.g. OMA DM [i.2], BBF [ref] TR-0069 [i.12] and LWM2M [ref]) data models, effectively making the considered resource manageable over these technologies. This can also be seen as the mgmtObj resource prototype “injecting” its four defined attributes into resources that one wants to become manageable over external management technologies. The notation used to show a mgmtObj prototype is {mgmtObj}” Remove the current attributes & child resources list for mgmtObj

Proposal – In Detail 3/4 Keep the text describing the mapping, like this: “When mapping resources from management technologies to a corresponding {mgmtObj} resource prototype, the following rules shall apply: – The root resource of external management objects maps to the {mgmtObj} resource prototype – For child resource of the root resource of specific technology: Rule1: If the child external management object cannot have a child external management object, the external management object maps to the [objectAttribute] attribute of the {mgmtObj} resource prototype with the same resource name; Rule2: If the child external management object can have another child external management object, the external management object maps to the child resource that shall also be a resource of the {mgmtObj} resource prototype – [Third bullet point deleted because the resource type was removed]

Proposal – In Detail 4/4 Keep the clause on the procedures, replacing every instance of “ resource” by “resource of {mgmtObj} prototype” Make the same replacement everywhere else in the spec Do consistency checks Modify TS-0005 and TS-0006 accordingly