MegaLinter Fix

code/API_definitions/Traffic_Influence.yaml

@@ -162,16 +162,17 @@ info:
     \
     **Device:**
     An user Device can be provided as an input. The Device can be identified by
-    the phone number (phoneNumber) or by its IP Address (Ipv4Address, Ipv6Address)
-    also specifying a Port. For IP address both the private (as seen from inside
-    the Device) and the public (as seen over Internet by a server connected to
-    the Device) can be used. To add more users the TI API must be invoked (POST)
-    of each user Device. New "TrafficInfluence" resources are created (with
-    different "trafficInfluenceID"). The routing toward the selected Application
-    instance is only applied for provided user Devices. "publicPort" can be used
-    to identify the device. "publicPort" can be also used to identify the flow
-    to be influenced. If the flow to be influenced is from a different public
-    port, "sourceTrafficFilters" can be used.\
+    the phone number (phoneNumber) or by its IP Address (Ipv4Address,
+    Ipv6Address) also specifying a Port. For IP address both the private (as
+    seen from inside the Device) and the public (as seen over Internet by a 
+    server connected to the Device) can be used. To add more users the TI API
+    must be invoked (POST) of each user Device. New "TrafficInfluence" 
+    resources are created (with different "trafficInfluenceID"). The routing
+    toward the selected Application instance is only applied for provided user
+    Devices. "publicPort" can be used to identify the device. "publicPort" can
+    be also used to identify the flow to be influenced. If the flow to be
+    influenced is from a different public port, "sourceTrafficFilters" can be
+    used.\
     \
     **Notification URL and token:**
     Developers can specify a callback URL on which notifications
@@ -740,22 +741,22 @@ components:
      description: |
       End-user equipment able to connect to a mobile network. Examples of
       devices include smartphones or IoT sensors/actuators.
-          The developer can choose to provide the below specified device
-          identifiers:
-          * `ipv4Address`
-          * `ipv6Address`
-          * `phoneNumber`
-          * `networkAccessIdentifier`
-          NOTE1: the MNO might support only a subset of these options.
-          The API invoker can provide multiple identifiers to be compatible
-          across different MNOs. In this case the identifiers MUST belong to
-          the same device.
-          NOTE2: for the Commonalities release v0.4, we are enforcing that the
-          networkAccessIdentifier is only part of the schema for
-          future-proofing, and CAMARA does not currently allow its use.
-          After the CAMARA meta-release work is concluded and the relevant
-          issues are resolved, its use will need to be explicitly documented
-          in the guidelines.
+      The developer can choose to provide the below specified device
+      identifiers:
+      * `ipv4Address`
+      * `ipv6Address`
+      * `phoneNumber`
+      * `networkAccessIdentifier`
+      NOTE1: the MNO might support only a subset of these options.
+      The API invoker can provide multiple identifiers to be compatible
+      across different MNOs. In this case the identifiers MUST belong to
+      the same device.
+      NOTE2: for the Commonalities release v0.4, we are enforcing that the
+      networkAccessIdentifier is only part of the schema for
+      future-proofing, and CAMARA does not currently allow its use.
+      After the CAMARA meta-release work is concluded and the relevant
+      issues are resolved, its use will need to be explicitly documented
+      in the guidelines.
      type: object
      properties:
       phoneNumber: