GSoS review discussion Point #3: How do we name clouds, systems, services, operations, devices and other components? Should there be both human-readable names and machine-readable names, or can one type of name be used for both?

[jerkerdelsing]

The naming convention paper by Cristina and me still make sense. Some cleaning will make it logically robust.
https://scholar.google.com/citations?view_op=view_citation&hl=sv&user=tqi6xEQAAAAJ&citation_for_view=tqi6xEQAAAAJ:WF5omc3nYNoC

This will provide both a human readable and machine usable naming enabling SoS mapping and analysis.

[jerkerdelsing]

From 17/8 meeting. Discussion to continue. No pressing need to make a strong definition here. A recommendation will be sufficient.

[CristinaPaniagua]

The following proposal has been defined in conjunction with Jens Eliasson (Thingwave).
Context
The last naming convention for the Eclipse Arrowhead framework was presented in 2019 (https://ieeexplore.ieee.org/abstract/document/8972250 ).
The proposal was not adopted by the community. Therefore, a revision and analysis of the same has been performed to identify the issues that led to this situation and to provide a better foundation for the new proposal.

The previous naming convention was based on DNS-SD and RFC-6335 recommendations.
There were several motives that hampered its adoption.

• Despite being based on DNS-SD the naming convention did not strictly follow a naming standard. It created its own description and it wasn’t supported by any widely used format.
• The complexity of the naming was too high. Too many elements and too long names. Dynamic creation.
• The creation of the chain between the arrowhead entities despite looking like a good idea, has been demonstrated not to be practical for the industry practices. The naming could not be created in the design phase since it required data from the deployment (e.g. The IPs, Ports, deployed devices) This over-complicated the naming that was a dynamic identifier and not a static one. The industry practice of marking the devices and changing the network IPs and ports over time means that using this naming will require updating the naming and an extra load for the users.

Considering the points made in this analysis we proposed the following naming convention.

Proposal

We propose the use of URN as a standard for all the naming.
URN stands for Uniform Resource Name and is a Uniform Resource Identifier (URI) that uses the urn scheme. URNs are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time. They are well-known and adopted.
To apply URN to the Eclipse Arrowhead framework, each entity in the framework will follow the proposed urn structure: urn + ea (eclipse arrowhead) + entity type + name/identifier type + name.

Therefore, the entities' naming looks like this:
Service -> urn:ea:srv:name: ------
System -> urn:ea:sys:name: ----- ( eac for core systems)
Device -> urn:ea:dev: name:----
urn:ea:dev: mac:---
urn:ea:dev:sn: ----
The devices will be identified depending on their characteristics. Resource constraint devices with only one Mac address will be identifiers with the MAC address, for middle resources a serial number can be used, finally, other resources and bigger devices will use a name or ID.

Local cloud -> urn: ea: cloud: name: ------- ( or ID)

The name field in the entities also can be used as an Alias.

Benefits of this approach:
• It is compliant with the URN standard. That is already known and easy to adopt.
• Simple and easy to adopt. The industry is already aware of this type of naming.
• More fields can be added in case of need. It is not restricted to a specific semantic or format.
• It is static. It can be defined in design time and used coherently on models, certificates, and physical labeling of the devices. Labeling the devices is a common practice in industry and it is not possible if the naming is not static. For dynamic information, the registries must be used.
• The changes on the devices, network, etc. do not affect the naming. This allows the decoupling of the entities and facilitates modifications over the engineering process without overengineering the SoS.

Usage in certificates:

The only restriction in the use of “:” in certificates is for public certificates used in webpages.
In order to prove the validity of the naming, a certificate has been created using keystore

[jerkerdelsing]

Put on hold to v5.1