Arrowhead core system v5.0.0 draft comments

[jerkerdelsing]

@PerOlofsson

ServiceRegistry SysD comments

Title - DONE
ServiceRegistry system description - SR SysD

We have since long used a naming convention on System and Services like
ServiceRegsitry (one word with capital S and R)
ServiceDiscovery (one word with capital S and D)

Section 1.2 - DONE

• SR is not properly defined!
• The ServiceRegistry system shall implement a service for administration activities, such as manual registration of services and manual removal of stale services.

A use case SysML/UML diagram shall be included in my opinion. Will help people undersand faster.

1.3 - DONE
Why will we allow a not time to live setting?

The Service Discovery endpoint would benefit from providing a preferred way of solving this.
DNS, broadcast every 5 minutes, .....

2.1 - REMIANS
Table should hold clickable links to the SD documents.
ServiceDiscovery
ServiceRegistryAdmin

3.1 - THE PREFERRED APPROACH IS WITH SECURITY
Since v5.0.0 is said to only work in secure mode
the ServiceRegistry shall only accept registration from producing systems having a valid local cloud certificate.
Look-up should be accepted from all systems having a valid local cloud certificate.

[jerkerdelsing]

ServiceDiscovery SD comments

2 - DONE
Arrowhead Cloud -> Arrowhead Local Cloud

OK
With a mandatory "Time to live" configuration the reregistration shall be described here.
The re-registration time need too findable from the ServiceDiscovery response to the Register operation.

2.1 & 2.2 SEE ABOVE COMMENT ON SysD
Again given the v5.0.0 decision to only allow secure mode operation.

• This operation shall be authenticated to prevent malicious registrations.

2.3 - OK
Lookup possible for anyone within the private local cloud network or having a valida local cloud certificate

3.1
I presume that the data structure need to contain also
MOVE THESE TO THE IDD

• protocol used (one IDD per protocol supported)
• eventual compression
• encoding = JSON

OK
Strongly preferred Meta data

• Data model ontology or standard used
• Response ontology/standard
• and may be e few more.

OK
IDD's do not need to be openly available

[emanuelpalm]

FYI, the documents under consideration are available at https://github.com/eclipse-arrowhead/roadmap/tree/main/5.0%20Draft/ServiceRegistry.

[jerkerdelsing]

ServiceRegistryAdministration SD comments

1.1 Significant prior are should point to ServiceRegistry 4.4.1

1.2
-The Service Registry Administration service is meant to be used to manually interact with the ServiceRegistry database.
Section 2

A table with the operations and links to associated IDD's is necessary.

2.1
The operation need to support search

3.1
I presume that the data structure need to contain also

protocol used (one IDD per protocol supported)
eventual compression
encoding = JSON
For each operation there is a response provided.
The response content need to be described. For details the IDD's should be consulted, see requested table above.

A security section is needed.
To be allowed to consume the service a valid local cloud admin certificate shall be needed.

[jerkerdelsing]

General comments to all SysD documents.

• Prior art need to build on previous Arrowhead versions and its basic architecture!!!
• What is the difference compared to current v4.4.0 - v4.6.0 where SysD's are available both in the core-java-spring and as SysD documents.
• How the system is ment to use require a use case senario which shows all expected usages to meet the Arrowhead architecture. Preferable a SysML use case model should be provided.
• Services: A service section should have a SysML model of the System and its produced and consumed service.
• Security need to be part of all Systems. Arrowhead architecture prescribes X.509 certificates as the basic security approach. This need to be reflected in all SysD's.

Whats is the argument to separate Authentication from the Authorisation system?

[jerkerdelsing]

SystemRegistry and DeviceRegistry
Sec 1.2
One purpose with the System and DeviceRegistries is the possibility to build a topology based using the registries content.

1.3
The Arrowhead architecture prescribes that each system shall clean it self from the SystemRegistry. In addition the registry shall have a time to life for which a re-registration is necessary. In SoSD such Time-to-Live" should be prescribed to a reasonable number e.g. 5 or 10 days. Thus this number should be possible to configure in the XRegistries and in any Arrowhead system. Thus forcing re-registration. This comment is valid for all 3 mandatory registries, ServiceRegistry, SystemRegistry and DeviceRegistry.

In addition see the general comments made above.

[jerkerdelsing]

Gatekeeper

1.2
To me this section reads that it's written by a person who have not read or understood the GateKeeper.

3.1 Security shall be specified to must have payload encryption and eventually Authentication and Authorisation as well dependent on used protocol. Please refer to the current Gateway Gatekeeper documentation.

[jerkerdelsing]

Orchestration system

1.1 use the correct Arrowhead version number v3 and v4 instead of generation 1 and 2.

1.2
The last paragraph mixes Orchestration with Workflow. Should be separated as in the current architecture.

1.3
Last paragraph is not compliant with defined service consumption capabilities.
QoS and Monitoring data analysis can be used for e.g. optimisations purpose. Any optimisation and changes of orchestration rule should reside in a separate "optimisation" system, an example is the Autonomic re-orchestration (see thesis by An Lam).

[PerOlofsson-Sinetiq]

General comments to all SysD documents.

• Prior art need to build on previous Arrowhead versions and its basic architecture!!!
• What is the difference compared to current v4.4.0 - v4.6.0 where SysD's are available both in the core-java-spring and as SysD documents.
• How the system is ment to use require a use case senario which shows all expected usages to meet the Arrowhead architecture. Preferable a SysML use case model should be provided.
• Services: A service section should have a SysML model of the System and its produced and consumed service.
• Security need to be part of all Systems. Arrowhead architecture prescribes X.509 certificates as the basic security approach. This need to be reflected in all SysD's.

Whats is the argument to separate Authentication from the Authorisation system?

1. I think it is okay to add a connection to the definition of the systems in the Generic SoSDD. That is in fact the basis for the selection of Core SysD:s in this documentation.
2. The 4.x version of SysD:s are reverse engineered from an implementation, not created from an Arrowhead architectural PoW.
3. I don´t follow your point. "All expected usages" are presumably not known since a user can select any combination of AH core systems in cooperation with their own implementations of core systems.
4. Ok. I think that a table is enough, but of course a figure of the core system with forks and lollipops are welcome.
5. Should we really prescribe X.509 certificates as an architectural choise? I´d rather leave this definition into the realization parts, for example in a SysDD of an authentication system. What about JWT token or SAML based authentication?
6. The argument for separating Authentication and Authorisation systems is the fact that they are separate functions. In the end they can be realized using different vendors. My best example is the swedish BankID, which offers authentication to a broad variety of systems/organisations without knowing anything about the rights that the identity is associated with within the organisations.

[PerOlofsson-Sinetiq]

SystemRegistry and DeviceRegistry Sec 1.2 One purpose with the System and DeviceRegistries is the possibility to build a topology based using the registries content.

1.3 The Arrowhead architecture prescribes that each system shall clean it self from the SystemRegistry. In addition the registry shall have a time to life for which a re-registration is necessary. In SoSD such Time-to-Live" should be prescribed to a reasonable number e.g. 5 or 10 days. Thus this number should be possible to configure in the XRegistries and in any Arrowhead system. Thus forcing re-registration. This comment is valid for all 3 mandatory registries, ServiceRegistry, SystemRegistry and DeviceRegistry.

In addition see the general comments made above.

1. Could you please elaborate somewhat when stating "build a topology" - what do you mean?
2. Valid point, we'll clarify. However, I think that we can prescribe the Registries to have this functionality, but I would not state that as a requirement of all Arrowhead systems. The rationale is that any application system might follow or not follow stated behaviour of the Registries, the Registries must be robust and handle non-compliant customers presumably at best effort. Not following this behaviour might cause the application system to loose Registrations.

[jerkerdelsing]

General comments to all SysD documents.

• Prior art need to build on previous Arrowhead versions and its basic architecture!!!
• What is the difference compared to current v4.4.0 - v4.6.0 where SysD's are available both in the core-java-spring and as SysD documents.
• How the system is ment to use require a use case senario which shows all expected usages to meet the Arrowhead architecture. Preferable a SysML use case model should be provided.
• Services: A service section should have a SysML model of the System and its produced and consumed service.
• Security need to be part of all Systems. Arrowhead architecture prescribes X.509 certificates as the basic security approach. This need to be reflected in all SysD's.

Whats is the argument to separate Authentication from the Authorisation system?

1. I think it is okay to add a connection to the definition of the systems in the Generic SoSDD. That is in fact the basis for the selection of Core SysD:s in this documentation.
2. The 4.x version of SysD:s are reverse engineered from an implementation, not created from an Arrowhead architectural PoW.
3. I don´t follow your point. "All expected usages" are presumably not known since a user can select any combination of AH core systems in cooperation with their own implementations of core systems.
4. Ok. I think that a table is enough, but of course a figure of the core system with forks and lollipops are welcome.
5. Should we really prescribe X.509 certificates as an architectural choise? I´d rather leave this definition into the realization parts, for example in a SysDD of an authentication system. What about JWT token or SAML based authentication?
6. The argument for separating Authentication and Authorisation systems is the fact that they are separate functions. In the end they can be realized using different vendors. My best example is the swedish BankID, which offers authentication to a broad variety of systems/organisations without knowing anything about the rights that the identity is associated with within the organisations.

1. OK
2. Still the 4.4-4.6 is the current architecture. We need to consider backward compatibility with what people understand and use. So I think it's very necessary to be able to discuss the differences!
3. The "all use cases" is to wide. But to foster some wider understanding including at least one use case is a good pedagogical practise.
4. Again a pedagogical support to the reader.
5. The current architectural principle is interoperability. The current architectural security is based on x.509 certificates. Using other security approaches like BankID should be possible but it will require a support for translation/handover of credentials between different security paradigms/technologoes. One approach for this is power of attorney which is being worked on by Sree and Olov.
6. Fully concur but it need to be connected to 5.

[jerkerdelsing]

SystemRegistry and DeviceRegistry Sec 1.2 One purpose with the System and DeviceRegistries is the possibility to build a topology based using the registries content.
1.3 The Arrowhead architecture prescribes that each system shall clean it self from the SystemRegistry. In addition the registry shall have a time to life for which a re-registration is necessary. In SoSD such Time-to-Live" should be prescribed to a reasonable number e.g. 5 or 10 days. Thus this number should be possible to configure in the XRegistries and in any Arrowhead system. Thus forcing re-registration. This comment is valid for all 3 mandatory registries, ServiceRegistry, SystemRegistry and DeviceRegistry.
In addition see the general comments made above.

1. Could you please elaborate somewhat when stating "build a topology" - what do you mean?
2. Valid point, we'll clarify. However, I think that we can prescribe the Registries to have this functionality, but I would not state that as a requirement of all Arrowhead systems. The rationale is that any application system might follow or not follow stated behaviour of the Registries, the Registries must be robust and handle non-compliant customers presumably at best effort. Not following this behaviour might cause the application system to loose Registrations.

1. We need a way of providing back annotation into technology documentation and implementation. Thus a live topology of the implementation is very desirable.
2. Prescribing this for all I think is important to reduce problems with ghost services, systems and devices, which will constitute a security problem and also affect various QoS parameters.

[borditamas]

AITIA comments for ServiceRegistry documents:

• According to the SysD and SD the Lookup operation is fully available for anyone within a Local Cloud. In AH 4.x.x versions the application systems (consumers/providers) are allowed to lookup only for core services (like "orchestration"), othervise the applications systems would be able to consume the given services without authorization rules.

• We are missing the the general data model descripton from the Service Discovery SD. The service cannot be implemented without knowing for example how to describe the interface.

• We are missing lot of implentation independent System and Service level features from the documents, which were highlighted and requested by the users and contributors to the previous versions. These SR related requiremets were collected once in issue Registries 5.0 Proposal #44

[jerkerdelsing]

@borditamas
fully open of only core system open look-up should be decided upon.
Implementation details are for the SysDD and IDD documents.