Create and enhance registration service type

[uwe-salomon]

Request summary: Create an object type for the registration service as standardized by CSMIM. Enhance the registration service by a lookup feature and add that to the type description.

Security Domain: core

Existing Types: None, but a description in the CSMIM standard.

New Types: csmim.obj.registration.1 csmim.obj.directory.1 or join with registration service.

Features:

Regarding the lookup feature: We already have the object ICDs being published in the network. This is sufficient if a particular object type of interest is only instantiated in few, well-known paths. If, on the other side, an object type can be instantiated in many places, a consumer would have to subscribe #/icd/# or similar, in consequence receiving many ICD messages and having to parse them to look for the object type of interest. Generic services like fault reporting or config reporting are particularly impacted by this problem. Every registration and re-registration in the network would send out a volley of ICD messages to these generic services.

One potential solution is to add a "directory service" to the network. This service would most likely be an intrinsic part of the registration service for efficiency reasons. Clients can send requests to the directory service, in order to be alerted when a new registration with certain properties is made. In particular, clients can request to be informed about all objects that have a certain object type of interest. This removes the need to subscribe to all ICD topics; a client would be informed only about the few registrations that are of concern actually.

As an example, a fault reporting service (a.k.a central maintenance service) could want to be informed about all objects that have the type csmim.obj.fault-report.1, wherever they are located in the network, but not from the pax domain.

This idea is similar to the CoRE Resource Directory [RFC 9176]. We might benefit from looking at their design and experience.

[uwe-salomon]

As a side note, we also discussed other solutions to this problem. One idea was to use a specifically prefixed object path for these "generic" object types. For example, a galley object might be published under the path crew/galley/galley/X1. But its fault report object would be published under the path crew/galley/faults/galley/X1. This way, a fault reporting service could directly subscribe the topic v1/data/crew/+/faults/# to get all fault reports in the crew domain. Which would be superior to first receiving all ICDs and then having to subscribe the individual objects of interest.

A drawback of this solution is that it requires a special prefix (such as "faults" in the example above) for all such situations. This prefix must be agreed on in advance. The object tree must be kept clean below this prefix. And proper use of the CSMIM protocol would actually require each client to verify the matching object type before accessing the resources.

[matthias-heinisch]

I like the proposal and think it is very useful. Especially as we expect various of these pervasive topics (configuration, health status, security logging, ...). But I am not convinced this should be integrated into registration service, as handling of individual requests and distribution lists will be complex. Maybe we can define a filter set that we provide instead of these individual queries? For example the registration could publish all ICDs and the directory service compiles different pre-defined subsets.

[uwe-salomon]

A concrete proposal for the topic structure:

• The directory service registers its object under core/csmim/directory
• This object currently has one resource csmim.obj
• Under this resource, each object registration is published in its own topic using the CSMIM extended topic feature. The extended topic consists of the object type ID (minus the "csmim.obj" prefix, and splitting the version suffix with a slash instead of a dot) and the path of that object.
• The payload of each published topic could be a timestamp or the actual object type ID.

Example

Say that some device registered a new object under the path crew/galley/left/x5 with the object type csmim.obj.galley.1 and the supertype csmim.obj.fault-report.1. This supertype is configured in the directory service to be a type of interest. Then the directory service publishes the following message:

PUBLISH v1/data/core/csmim/directory/csmim.obj/fault-report/1/crew/galley/left/x5
QoS: 1
Retain: true
Payload:
  csmim.obj.galley.1

A fault reporting service would have to

• subscribe v1/data/core/csmim/directory/csmim.obj/fault-report/# in order to obtain a message for each registered object that derives from "csmim.obj.fault-report.N"
• parse the extended topic to retrieve the object type version number and the object path
• verify that it knows the "csmim.obj.fault-report.N" version
• subscribe to the announced faults resource

In the example, the fault reporting service would have to subscribe to the crew/galley/left/x5/faults resource (assuming that a fault reporter is defined to contain such a resource faults).

Notes

• The version number for object type IDs is optional. The directory service would have to detect a missing version number and insert an empty // into the topic.