Sinetiq version for Arrowhead Pull Request

Final fixings, removal of additional information from IDD templates.
eclipse-arrowhead · Feb 13, 2024 · 7967171 · 7967171
1 parent 98e111e
commit 7967171
Show file tree

Hide file tree

Showing 7 changed files with 70 additions and 183 deletions.
diff --git a/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml b/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml
@@ -58,14 +58,6 @@ info:
     payloads up to 4096 bytes in size. If payload compression is supported, then this limit applies
     after decompression.
   version: 5.0.0-rc.1
-
-  # Additional information present in the IDD template
-  x-transfer-protocol: [HTTP, HTTPS]
-  x-encryption-method: to-add
-  x-encoding: JSON
-  x-compression: to-add
-  x-semantics: to-add
-  x-Ontology: to-add
 
 paths:
 

diff --git a/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-management-http-json.yml b/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-management-http-json.yml
@@ -36,13 +36,6 @@ info:
 
 
   version: 1.0.0
-  # Additional information present in the IDD template
-  x-transfer-protocol: [HTTP, HTTPS]
-  x-encryption-method: to-add
-  x-encoding: JSON
-  x-compression: to-add
-  x-semantics: to-add
-  x-Ontology: to-add
 
 paths:
   /ping:

diff --git a/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-pull-http-json.yml b/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-pull-http-json.yml
@@ -3,12 +3,11 @@ openapi: 3.0.3
 info:
   title: Service Orchestration-pull service API description 
   description: |
-    An API for using the Service Orchestration-pull service of the Orchestration core system. This service
-    uses the orchestration store policies to recommend service providers to the requesting consumer to fulfil 
-    its task. 
+    An API for using the Service Orchestration-pull service of the Orchestration core system. This service uses the orchestration store policies 
+    to recommend service providers to the requesting consumer to fulfil its task. 
 
-    The consumer system request for orchestration either by specifying the service definition that the consumer requires or 
-    by using stored SoS configurations or Orchestration rules if no service information is defined. 
+    The consumer system request for orchestration either by specifying the service definition that the consumer requires or by using stored SoS 
+    configurations or Orchestration rules if no service information is defined. 
 
     _SoS configurations_ represents the connections needed in a SoS for it to perform its designed task. This means, describing what services
     must each of the systems consume to perform their individual tasks. A SoS configuration can be seen as a series of _Orchestration rules_.
@@ -17,18 +16,10 @@ info:
     In the context of this document, we reffer to the Orchestration consumer as _requesting-system_ where _system-id_ is the
     unique identifier that represents that system. The _requested-service_ represents the service information that the _requesting-system_
     requires orchestration. In case the _requested_service_ is specified, the requires service definition must be included in the form, 
-    in addition, at least one interface must be specified. The orchestration system will attempt to match the _requested-service_ information
-    with services present on the orchestration rules or SoS configurations. 
-  version: 5.0.0-rc.1
-
+    The orchestration system will attempt to match the _requested-service_ information with services present on the orchestration rules or SoS 
+    configurations. 
 
-# Additional information present in the IDD template
-x-transfer-protocol: [HTTP, HTTPS]
-x-encryption-method: to-add
-x-encoding: JSON
-x-compression: to-add
-x-semantics: to-add
-x-Ontology: to-add
+  version: 5.0.0-rc.1
 
 paths:
   /orchestration/echo:
@@ -47,7 +38,7 @@ paths:
         on a existing SoS configuration or Orchestration rules. 
 
         Information of the requesting system is mandatory. Requested service is optional. If a requested service object is specified,
-        the service definition and at least one interface must be specified. 
+        the service definition must be specified. 
       requestBody:
         required: true
         content:
@@ -91,63 +82,13 @@ paths:
 
 components:
   schemas:
-    Address:
-      description: |
-        Identifies a _transport_ and a _location_.
-
-        The _transport_ identifies the base protocol that facilitates addressing a specific service
-        instance. Examples of transports that can be supported are `tcp4`, `tcp6`, `udp4`, `udp6`
-        and `unix`. A protocol only counts as a transport if it both (A) provides a way of
-        addressing and, by extension, sending messages to service providers and consumers, as well
-        as (B) does not build upon another protocol also providing this capability. I other words,
-        TLS and DTLS are _not_ transports, because they build upon the TCP and UDP protocols, which
-        satisfy condition A.
-
-        What the _location_ part consists of depends on what transport is identified. If the
-        transport is `tcp4` or `udp4`, the location is an IPv4 address expressed as four decimal
-        numbers separated by dots, a colon and a port number, such as in `192.168.3.22:64075`. If
-        the transport is `tcp6` or `udp6`, the location is an IPv6 address, rendered as described in
-        [RFC 5952](https://www.rfc-editor.org/rfc/rfc5952), within square brackets, followed by a
-        colon and a port number. If the transport is `unix`, the location is an absolute filesystem
-        path to a Unix socket file.
-      type: string
-      pattern: ^(?<transport>[^:]+):\w*(?<location>.*)$
-      example: tcp4:192.168.0.7:45326
 
     Auth-tokens:
       description: |
-        An (k,v) object containing authorization tokens for each interface contained in the response
+        An (k,v) object containing authorization tokens required to consume orchestration services
       type: object
       example: {"interfaceName1":"token1"}
 
-    Interface:
-      description: An object describing interfaces used by services. This object contains information on the used 
-        protocol and the security requirements. Depending on the protocol, additional properties could be appropriate,
-        such as 'version', 'contentTypes', 'ipv4Address', 'port', 'x509PublicKey', 'basePath' or 'topic'. The same 
-        applying to security. 
-      type: object
-      properties:
-        protocol:
-          type: object
-          properties:
-            name:
-              type: string
-              description: "Transport protocol, such as 'https', 'coaps+tcp', 'json-rpc', or 'mqtt'"
-              additionalProperties: true
-          required:
-            - name
-        security:
-          type: array
-          items:
-            type: object
-            properties:
-              name:
-                type: string
-                description: "Security method name, such as 'tokenAuthentication'"
-                additionalProperties: true
-            required:
-              - name
-
     Metadata:    
       description: |
         Additional details of relevance when consuming a service. What metadata is made available
@@ -156,56 +97,7 @@ components:
       type: object
       example: {"basePath":"v2"}
 
-    PreferredProvider:
-      type: object
-      description: information of a preferred provider to consume services from.
-      properties:
-        provider-cloud:
-          $ref: '#/components/schemas/ProviderCloud'
-        provider:
-          $ref: '#/components/schemas/ProviderSystem'
-
-    ProviderSystem:
-      type: object
-      description: information describing a provider system within a local cloud. 
-      properties:
-        system-name:
-          type: string
-        address:
-          $ref: '#/components/schemas/Address'
-
-    ProviderCloud:
-      type: object
-      description: an object describing the cloud in which a provider is located
-      properties:
-        operator:
-          type: string
-          description: Name of the operator company
-        name: 
-          type: string
-          description: name of the cloud 
-
-    RequesterSystem:
-      type: object
-      description: Information of the system requesting orchestration information. 
-      properties:
-        system-name: 
-          type: string
-          description: Short human readable system name.
-        systemID:
-          type: string
-          description: unique identifier of requester system
-        address: 
-          $ref: '#/components/schemas/Address'
-        auth-info:
-          type: string
-          description: Authentication info, i.e, CERTIFICATE, TOKEN, etc. 
-        interface: 
-          type: array
-          items:
-            $ref: '#/components/schemas/Interface'
-
-    RequestedService: #TODO: How much of this information should be asked? 
+    RequestedService:
       type: object
       description: |
         Optional information of the required service. This object contains the service requirements of the requester
@@ -214,11 +106,9 @@ components:
         service-definition:
           type: string
           description: Service definition string identifier
-        interfaces:
-          type: array
-          description: Interface requirement 
-          items:
-            $ref: '#/components/schemas/Interface'
+        service-type:
+          type: string
+          description: Service type string identifier
         version:
           $ref: '#/components/schemas/VersionReq'
       required:
@@ -232,13 +122,6 @@ components:
           description: service instance unique identifier, the consumer getting the response use this to query the service registry to get 
             full service information and connection address.
 
-    SecurityType:
-      type: string
-      enum:
-        - TOKEN
-        - NON-SECURE
-        - CERTIFICATE
-
     ServiceRequestForm:
       type: object
       properties:
@@ -250,10 +133,6 @@ components:
           description: Requesting system unique identifier
         requested-service:
           $ref: '#/components/schemas/RequestedService'
-        preferred-providers:
-          type: array
-          items:
-            $ref: '#/components/schemas/PreferredProvider'
 
     OrchestrationResponse:
       type: object

diff --git a/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-push.yml b/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-push.yml
@@ -15,14 +15,6 @@ info:
 
 version: 5.0.0-rc.1
 
-# Additional information present in the IDD template
-x-transfer-protocol: [to-add]
-x-encryption-method: to-add
-x-encoding: JSON
-x-compression: to-add
-x-semantics: to-add
-x-Ontology: to-add
-
 channels:
   pushConfiguration:
     address: 'orchestration/push'
@@ -78,9 +70,10 @@ components:
           items: 
             $ref: '#/components/schemas/Rule'
         target: 
-          type: object
+          type: array
           description: Target of the orchestration configuration
-          #TODO: define how the target should look like, is it just one target? is it an array of targets? Are the targets within the rules?
+          items: 
+            $ref: '#/components/schemas/System'
 
     Metadata:    
       description: |

diff --git a/...t/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-store-management-http-json.yml b/...t/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-store-management-http-json.yml
@@ -19,13 +19,6 @@ info:
     is valid in the local cloud. 
   version: 5.0.0-rc.1
 
-# Additional information present in the IDD template
-x-transfer-protocol: [HTTP, HTTPS]
-x-encryption-method: to-add
-x-encoding: JSON
-x-compression: to-add
-x-semantics: to-add
-x-Ontology: to-add
 
 paths:
   /orchestration/rules:
@@ -234,9 +227,14 @@ components:
         serviceID:
           type: string
           description: identifier of service
-        serviceInstance:
+        serviceDefinition:
           type: string
           description: name of the service instance
+        serviceType:
+          type: string
+          description: name of the service type
+        version: 
+          $ref: '#/components/schemas/Version'
 
     System:
       type: object
@@ -253,3 +251,10 @@ components:
       pattern: ^(?:(\d+)d)?(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?$
       example: 2d12h
 
+    Version:
+      description: |
+        A MAJOR, MINOR and a PATCH number, separated by dots. If both or the latter of the MINOR and
+        PATCH numbers are omitted, the ones omitted are assumed to be zero.
+      type: string
+      pattern: ^\d+(?:\.\d+(?:\.\d+)?)?$
+      example: 1.4
diff --git a/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-discovery-http-json.yml b/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-discovery-http-json.yml
@@ -49,7 +49,6 @@ info:
     Every service instance registered via this service interface _must_ be associated with a unique
     identifier. In contexts where authentication is not used, providers _must_ chose their own
     identifiers. Those identifiers _should_ remain consistent between restarts of those providers.
-    In contexts where authentication is used, the identifier _must_ be derived as follows: TODO.
 
     ## Size Limits
 
@@ -59,13 +58,6 @@ info:
     limit the sizes of individual parts within each request. It _must_, however, receive request
     URI:s up to 2816 bytes in size, as well as request payloads up to 4096 bytes in size.
   version: 5.0.0-rc.1
-  # Additional information present in the IDD template
-  x-transfer-protocol: [HTTP, HTTPS]
-  x-encryption-method: to-add
-  x-encoding: JSON
-  x-compression: to-add
-  x-semantics: to-add
-  x-Ontology: to-add
 
 paths:
 

diff --git a/...raft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml b/...raft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml
@@ -8,15 +8,48 @@ info:
     registry catalog. To register a service, the service provider, a system administrator, or a supporting system
     must fill a _ServiceEntry_  object with the details of the service and the service provider. Additional 
     inforation can be especified in the _metadata_ parameter. 
-  version: 1.0.0
-  # Additional information present in the IDD template
-  x-transfer-protocol: [HTTP, HTTPS]
-  x-encryption-method: to-add
-  x-encoding: JSON
-  x-compression: to-add
-  x-semantics: to-add
-  x-Ontology: to-add
 
+    ## Compression and Language
+
+    An implementation of this service interface _may_ be designed to support compression and/or
+    human-readable error texts in different languages than English, as described in 
+    [RFC 9110, Section 12](https://www.rfc-editor.org/rfc/rfc9110#name-content-negotiation). Not
+    using compression _must_ be supported and be the default. Also, the default language for error
+    messages _must_ be American English (`en-US`).
+
+    ## Managing Record Life-Cycles
+
+    In a typical use case, this service interface is meant to hold records for all service providers
+    currently part of its context. When a service provider joins or leaves a context, it is expected
+    to register and deregister its services, respectively. However, service providers can fail or be
+    detached from the context before they get a chance to deregister their services. This can make
+    it relevant to monitor service providers and temporarily suppress or permanently prune records
+    associated with unhealthy or inaccessible providers. Implementations of this service interface
+    are free to suppress and/or prune records in whatever way best supports the use cases they are
+    designed for.
+
+    ## Record Ownership
+
+    It is the provider indicated inside each record that is the owner of the record, and not the
+    consumer registering it. This means that a consumer may be forbidden from registering or
+    deregistering a record for certain or all other service providers, even if it may register
+    and/or deregister records with itself as provider.
+
+    ## Provider Identifiers
+
+    Every service instance registered via this service interface _must_ be associated with a unique
+    identifier. In contexts where authentication is not used, providers _must_ chose their own
+    identifiers. Those identifiers _should_ remain consistent between restarts of those providers.
+
+    ## Size Limits
+
+    As a mitigation against denial-of-service attacks, all implementations of this service
+    interface _should_ reject incoming requests that are larger than a predefined limit. That limit
+    _must not_ be smaller than 8192 bytes for each received request. An implementation _may_ also
+    limit the sizes of individual parts within each request. It _must_, however, receive request
+    URI:s up to 2816 bytes in size, as well as request payloads up to 4096 bytes in size.
+
+  version: 1.0.0
 
 paths:
   /service-registry/list: