diff --git a/SOL003/VNFFaultManagement-API_egm/Alarms.robot b/SOL003/VNFFaultManagement-API_egm/Alarms.robot
new file mode 100644
index 0000000000000000000000000000000000000000..2f3ca9303c59c2d70164492b4c07c3d7f6d3a050
--- /dev/null
+++ b/SOL003/VNFFaultManagement-API_egm/Alarms.robot
@@ -0,0 +1,72 @@
+*** Settings ***
+# Suite setup Expect spec SOL003-VNFLifecycleManagement-API.yaml
+Resource variables.txt
+Library REST http://${VNFM_HOST}:${VNFM_PORT}
+... spec=SOL003-VNFFaultManagement-API.yaml
+
+*** Test cases ***
+POST Alarms - Method not implemented
+ log Trying to perform a PUT. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Post ${apiRoot}/${apiName}/${apiVersion}/alarms
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+Get information about multiple alarms
+ Log Query VNF The GET method queries information about multiple alarms.
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Log Execute Query and validate response
+ Get ${apiRoot}/${apiName}/${apiVersion}/alarms
+ Output response
+ Log Validate Status code
+ Integer response status 200
+
+Get information about multiple alarms with filters
+ Log Query VNF The GET method queries information about multiple alarms with filters.
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Log Execute Query and validate response
+ Get ${apiRoot}/${apiName}/${apiVersion}/alarms?${alarm_filter}=${managedObjectId}
+ Output response
+ Log Validate Status code
+ Integer response status 200
+
+Get information about multiple alarms Bad Request Invalid attribute-based filtering parameters
+ Log Query VNF The GET method queries information about multiple VNF instances.
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Get ${apiRoot}/${apiName}/${apiVersion}/alarms?${invalid_alarm_filter}=${managedObjectId}
+ Log Validate Status code
+ Output response
+ Integer response status 400
+
+PUT Alarms - Method not implemented
+ log Trying to perform a PUT. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Put ${apiRoot}/${apiName}/${apiVersion}/alarms
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+PATCH Alarms - Method not implemented
+ log Trying to perform a PATCH. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Patch ${apiRoot}/${apiName}/${apiVersion}/alarms
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+DELETE Alarms - Method not implemented
+ log Trying to perform a DELETE. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Delete ${apiRoot}/${apiName}/${apiVersion}/alarms
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
diff --git a/SOL003/VNFFaultManagement-API_egm/IndividualAlarm.robot b/SOL003/VNFFaultManagement-API_egm/IndividualAlarm.robot
new file mode 100644
index 0000000000000000000000000000000000000000..404984d52e54512b5d079e12d77716c2dbc8013f
--- /dev/null
+++ b/SOL003/VNFFaultManagement-API_egm/IndividualAlarm.robot
@@ -0,0 +1,97 @@
+*** Settings ***
+# Suite setup Expect spec SOL003-VNFLifecycleManagement-API.yaml
+Resource variables.txt
+Library REST http://${VNFM_HOST}:${VNFM_PORT}
+... spec=SOL003-VNFFaultManagement-API.yaml
+Library OperatingSystem
+Library DependencyLibrary
+
+*** Variables ***
+${Etag}= an etag
+${Etag_modified}= a modified etag
+
+*** Test cases ***
+POST Alarm - Method not implemented
+ log Trying to perform a PUT. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Post ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+Get information about an alarm
+ Log Query VNF The GET method queries information about multiple alarms.
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Log Execute Query and validate response
+ Get ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
+ Output response
+ ${Etag}= Output response headers Etag
+ Log Validate Status code
+ Integer response status 200
+
+PUT Alarm - Method not implemented
+ log Trying to perform a PUT. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Put ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+PATCH Alarm
+ [Documentation] This method modifies an individual alarm resource
+ log Trying to perform a PATCH. This method modifies an individual alarm resource
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ ${body}= Get File json/alarmModifications.json
+ Patch ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId} ${body}
+ Log Validate Status code
+ Output response
+ ${Etag_modified}= Output response headers Etag
+ Integer response status 200
+
+PATCH Alarm - Conflict
+ [Documentation] Conflict
+ ... The operation cannot be executed currently, due to a conflict with the state of the “Individual alarm” resource.
+ ... Typically, this is due to the fact that the alarm is already in the state that is requested to be set (such as trying to acknowledge an already-acknowledged alarm).
+ ... The response body shall contain a ProblemDetails structure, in which the “detail” attribute should convey more information about the error.
+ Depends On Test PATCH Alarm # If the previous test scceeded, it means that the alarm is in ackownledged state
+ log Trying to perform a PATCH. This method modifies an individual alarm resource
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ ${body}= Get File json/alarmModifications.json
+ Patch ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId} ${body}
+ Log Validate Status code
+ Output response
+ Integer response status 409
+
+PATCH Alarm - Precondition failed
+ [Documentation] Precondition Failed
+ ... A precondition given in an HTTP request header is not fulfilled. Typically, this is due to an ETag mismatch,
+ ... indicating that the resource was modified by another entity. The response body should contain a ProblemDetails structure,
+ ... in which the “detail” attribute should convey more information about the error.
+ Depends On Test PATCH Alarm # If the previous test scceeded, it means that Etag has been modified
+ log Trying to perform a PATCH. This method modifies an individual alarm resource
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"}
+ Set Headers {"If-Match": "${Etag}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ ${body}= Get File json/alarmModifications.json
+ Patch ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId} ${body}
+ Log Validate Status code
+ Output response
+ Integer response status 412
+
+DELETE Alarm - Method not implemented
+ log Trying to perform a DELETE. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Delete ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
+ Log Validate Status code
+ Output response
+ Integer response status 405
diff --git a/SOL003/VNFFaultManagement-API_egm/SOL003-VNFFaultManagement-API.yaml b/SOL003/VNFFaultManagement-API_egm/SOL003-VNFFaultManagement-API.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..b362b74e768554bbf2c8b7f499afc5ac00b8bd56
--- /dev/null
+++ b/SOL003/VNFFaultManagement-API_egm/SOL003-VNFFaultManagement-API.yaml
@@ -0,0 +1,5219 @@
+swagger: '2.0'
+info:
+ version: 1.1.1
+ title: SOL003 - VNF Fault Management interface
+ description: >
+ SOL003 - VNF Fault Management interface
+
+
+ IMPORTANT: Please note that this file might be not aligned to the current
+ version of the ETSI Group Specification it refers to. In case of
+ discrepancies the published ETSI Group Specification takes precedence.
+
+
+ In clause 4.3.2 of ETSI GS NFV-SOL 003 v2.4.1, an attribute-based filtering
+ mechanism is defined. This mechanism is currently not included in the
+ corresponding OpenAPI design for this GS version. Changes to the
+ attribute-based filtering mechanism are being considered in v2.5.1 of this
+ GS for inclusion in the corresponding future ETSI NFV OpenAPI design.
+
+ Please report bugs to
+ https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=
+ license:
+ name: ETSI Forge copyright notice
+ url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt'
+externalDocs:
+ description: ETSI GS NFV-SOL 003 V2.4.1
+ url: >-
+ http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf
+basePath: /vnffm/v1
+schemes:
+ - https
+consumes:
+ - application/json
+produces:
+ - application/json
+paths:
+ /alarms:
+ get:
+ description: >
+ Get Alarm List
+
+
+ The client can use this method to retrieve information about the alarm
+ list.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '200':
+ description: >
+ OK
+
+ The request has succeeded. The response body shall contain the list
+ of related alarms.
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the request. Reference: IETF RFC
+ 7231
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ $ref: '#/definitions/Alarm'
+ '400':
+ description: >
+ Bad Request
+
+ Invalid attribute-based filtering parameters or Invalid attribute
+ selector. It fhe request is malformed or syntactically incorrect
+ (e.g. if the request URI contains incorrect query parameters or a
+ syntactically incorrect payload body), the API producer shall
+ respond with this response code. The "ProblemDetails" structure
+ shall be provided, and should include in the "detail" attribute more
+ information about the source of the problem. If the request contains
+ a malformed access token, the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided. If there is
+ an application error related to the client's input that cannot be
+ easily mapped to any other HTTP response code ("catch all error"),
+ the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '/alarms/{alarmId}':
+ parameters:
+ - name: alarmId
+ description: >
+ Identifier of the alarm. This identifier can be retrieved from the
+ "id" attribute of the "alarm" attribute in the AlarmNotification or
+ AlarmClearedNotification. It can also be retrieved from the "id"
+ attribute of the applicable array element in the payload body of the
+ response to a GET request to the "Alarms" resource.
+ in: path
+ type: string
+ required: true
+ get:
+ description: |
+ The client can use this method to read an individual alarm.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Content-Type
+ description: |
+ The MIME type of the body of the request. Reference: IETF RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '200':
+ description: >
+ OK
+
+ Information about an individual alarm was read successfully. The
+ response body shall contain a representation of the individual
+ alarm.
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the request. Reference: IETF RFC
+ 7231
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ $ref: '#/definitions/Alarm'
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ patch:
+ description: |
+ Acknowledge Alarm
+
+ This method modifies an individual alarm resource.
+ parameters:
+ - name: AlarmModifications
+ description: The VNF creation parameters
+ in: body
+ required: true
+ schema:
+ $ref: '#/definitions/AlarmModifications'
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ - name: Content-Type
+ description: >
+ The Content-Type header shall be set to
+ "application/merge-patch+json" according to IETF RFC 7396.
+ in: header
+ required: true
+ type: string
+ enum:
+ - application/merge-patch+json
+ responses:
+ '200':
+ description: >
+ OK
+
+ The request was accepted and completed. The response body shall
+ contain attribute modifications for an ‘Individual alarm’ resource.
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the request. Reference: IETF RFC
+ 7231
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ $ref: '#/definitions/AlarmModifications'
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '409':
+ description: >
+ Conflict
+
+ The operation cannot be executed currently, due to a conflict with
+ the state of the "Individual alarm" resource. Typically, this is due
+ to the fact that the alarm is already in the state that is requested
+ to be set (such as trying to acknowledge an already-acknowledged
+ alarm). The response body shall contain a ProblemDetails structure,
+ in which the "detail" attribute should convey more information about
+ the error.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '412':
+ description: >
+ Precondition Failed
+
+ A precondition given in an HTTP request header is not fulfilled.
+ Typically, this is due to an ETag mismatch, indicating that the
+ resource was modified by another entity. The response body should
+ contain a ProblemDetails structure, in which the "detail" attribute
+ should convey more information about the error.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ /subscriptions:
+ post:
+ description: >
+ Subscribe
+
+
+ The POST method creates a new subscription. Creation of two subscription
+ resources with the same callbackURI and the same filter can result in
+ performance degradation and will provide duplicates of notifications to
+ the NFVO, and might make sense only in very rare use cases.
+ Consequently, the VNFM may either allow creating a subscription resource
+ if another subscription resource with the same filter and callbackUri
+ already exists (in which case it shall return the “201 Created†response
+ code), or may decide to not create a duplicate subscription resource (in
+ which case it shall return a “303 See Other†response code referencing
+ the existing subscription resource with the same filter and
+ callbackUri).
+ parameters:
+ - name: FmSubscriptionRequest
+ description: The VNF creation parameters
+ in: body
+ required: true
+ schema:
+ $ref: '#/definitions/FmSubscriptionRequest'
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ - name: Content-Type
+ description: |
+ The MIME type of the body of the request. Reference: IETF RFC 7231
+ in: header
+ required: true
+ type: string
+ responses:
+ '201':
+ description: >
+ Created
+
+ The subscription was created successfully. The response body shall
+ contain a representation of the created subscription resource. The
+ HTTP response shall include a "Location:" HTTP header that points to
+ the created subscription resource.
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the request. Reference: IETF RFC
+ 7231
+ type: string
+ maximum: 1
+ minimum: 1
+ Location:
+ description: |
+ The resource URI of the created subscription resource.
+ type: string
+ format: url
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ $ref: '#/definitions/FmSubscription'
+ '303':
+ description: >
+ See Other
+
+ A subscription with the same callbackURI and the same filter already
+ exists and the policy of the VNFM is to not create redundant
+ subscriptions. The HTTP response shall include a "Location" HTTP
+ header that contains the resource URI of the existing subscription
+ resource. The response body shall be empty.
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ get:
+ description: >
+ Query Subscription Information
+
+
+ The client can use this method to retrieve the list of active
+ subscriptions for VNF alarms subscribed by the client. It can be used
+ e.g. for resynchronization after error situations.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ - name: Content-Type
+ description: |
+ The MIME type of the body of the request. Reference: IETF RFC 7231
+ in: header
+ required: true
+ type: string
+ responses:
+ '200':
+ description: >
+ OK
+
+ The list of subscriptions was queried successfully. The response
+ body shall contain the representations of all active subscriptions
+ of the functional block that invokes the method.
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the request. Reference: IETF RFC
+ 7231
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ $ref: '#/definitions/FmSubscription'
+ '400':
+ description: >
+ Bad Request
+
+ Invalid attribute-based filtering parameters or Invalid attribute
+ selector. It fhe request is malformed or syntactically incorrect
+ (e.g. if the request URI contains incorrect query parameters or a
+ syntactically incorrect payload body), the API producer shall
+ respond with this response code. The "ProblemDetails" structure
+ shall be provided, and should include in the "detail" attribute more
+ information about the source of the problem. If the request contains
+ a malformed access token, the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided. If there is
+ an application error related to the client's input that cannot be
+ easily mapped to any other HTTP response code ("catch all error"),
+ the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '412':
+ description: >
+ Precondition Failed
+
+ A precondition given in an HTTP request header is not fulfilled.
+ Typically, this is due to an ETag mismatch, indicating that the
+ resource was modified by another entity. The response body should
+ contain a ProblemDetails structure, in which the "detail" attribute
+ should convey more information about the error.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '/subscriptions/{subscriptionId}':
+ parameters:
+ - name: subscriptionId
+ description: >
+ Identifier of this subscription. This identifier can be retrieved from
+ the resource referenced by the "Location" HTTP header in the response
+ to a POST request creating a new subscription resource. It can also be
+ retrieved from the "id" attribute in the payload body of that
+ response.
+ in: path
+ type: string
+ required: true
+ get:
+ description: >
+ Query Subscription Information
+
+
+ The client can use this method for reading an individual subscription
+ for VNF alarms subscribed by the client.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ - name: Content-Type
+ description: |
+ The MIME type of the body of the request. Reference: IETF RFC 7231
+ in: header
+ required: true
+ type: string
+ responses:
+ '200':
+ description: >
+ OK
+
+ The operation has completed successfully. The response body shall
+ contain a representation of the subscription resource.
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the request. Reference: IETF RFC
+ 7231
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ $ref: '#/definitions/FmSubscription'
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ delete:
+ description: |
+ Terminate Subscription
+
+ This method terminates an individual subscription.
+ parameters:
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '204':
+ description: >
+ No Content
+
+ The subscription resource was deleted successfully. The response
+ body shall be empty.
+ headers:
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+definitions:
+ Alarm:
+ description: |
+ The alarm data type encapsulates information about an alarm.
+ type: object
+ required:
+ - id
+ - managedObjectId
+ - rootCauseFaultyResource
+ - alarmRaisedTime
+ - ackState
+ - perceivedSeverity
+ - eventTime
+ - eventType
+ - probableCause
+ - isRootCause
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ managedObjectId:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ rootCauseFaultyResource:
+ description: >
+ This type represents the faulty virtual resources that have a negative
+ impact on a VNF.
+ type: object
+ required:
+ - faultyResource
+ - faultyResourceType
+ properties:
+ faultyResource:
+ required:
+ - vimConnectionId
+ - resourceId
+ type: object
+ description: >
+ This type represents the information that allows addressing a
+ virtualised resource that is used by a VNF instance. Information
+ about the resource is available from the VIM.
+ properties:
+ vimConnectionId:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ resourceProviderId:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ resourceId:
+ description: >
+ An identifier maintained by the VIM or other resource
+ provider. It is expected to be unique within the VIM instance.
+ type: string
+ vimLevelResourceType:
+ description: >
+ Type of the resource in the scope of the VIM or the resource
+ provider.
+ type: string
+ faultyResourceType:
+ description: >
+ The enumeration FaultyResourceType represents those types of
+ faulty resource.
+ type: string
+ enum:
+ - COMPUTE
+ - STORAGE
+ - NETWORK
+ alarmRaisedTime:
+ description: >
+ Date-time stamp. Representation: String formatted according to IETF
+ RFC 3339.
+ type: string
+ format: date-time
+ alarmChangedTime:
+ description: >
+ Date-time stamp. Representation: String formatted according to IETF
+ RFC 3339.
+ type: string
+ format: date-time
+ alarmClearedTime:
+ description: >
+ Date-time stamp. Representation: String formatted according to IETF
+ RFC 3339.
+ type: string
+ format: date-time
+ ackState:
+ description: >
+ Acknowledgement state of the alarm. Permitted values: *
+ UNACKNOWLEDGED * ACKNOWLEDGED.
+ type: string
+ enum:
+ - UNACKNOWLEDGED
+ - ACKNOWLEDGED
+ perceivedSeverity:
+ description: >
+ Indicates the relative level of urgency for operator attention. *
+ CRITICAL: The Critical severity level indicates that a service
+ affecting condition has occurred and an immediate corrective action
+ is required. Such a severity can be reported, for example, when a
+ managed object becomes totally out of service and its capability needs
+ to be restored (ITU-T Recommendation X.733).
+ * MAJOR: The Major severity level indicates that a service affecting
+ condition has developed and an urgent corrective action is required.
+ Such a severity can be reported, for example, when there is a severe
+ degradation in the capability of the managed object and its full
+ capability needs to be restored (ITU-T Recommendation X.733).
+ * MINOR: The Minor severity level indicates the existence of a
+ non-service affecting fault condition and that corrective action
+ should be taken in order to prevent a more serious (for example,
+ service affecting) fault. Such a severity can be reported, for
+ example, when the detected alarm condition is not currently degrading
+ the capacity of the managed object (ITU-T Recommendation X.733).
+ * WARNING: The Warning severity level indicates the detection of a
+ potential or impending service affecting fault, before any significant
+ effects have been felt. Action should be taken to further diagnose (if
+ necessary) and correct the problem in order to prevent it from
+ becoming a more serious service affecting fault (ITU-T Recommendation
+ X.733).
+ * INDETERMINATE: The Indeterminate severity level indicates that the
+ severity level cannot be determined (ITU-T Recommendation X.733).
+ * CLEARED: The Cleared severity level indicates the clearing of one or
+ more previously reported alarms. This alarm clears all alarms for this
+ managed object that have the same Alarm type, Probable cause and
+ Specific problems (if given) (ITU-T Recommendation X.733).
+ type: string
+ enum:
+ - CRITICAL
+ - MAJOR
+ - MINOR
+ - WARNING
+ - INDETERMINATE
+ - CLEARED
+ eventTime:
+ description: >
+ Date-time stamp. Representation: String formatted according to IETF
+ RFC 3339.
+ type: string
+ format: date-time
+ eventType:
+ description: >
+ The enumeration EventType represents those types of events that
+ trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is
+ associated with the
+ procedure and/or process required conveying information from one point
+ to another (ITU-T Recommendation X.733).
+ * PROCESSING_ERROR_ALARM: An alarm of this type is associated with a
+ software or processing fault (ITU-T Recommendation X.733).
+ * ENVIRONMENTAL_ALARM: An alarm of this type is associated with a
+ condition related to an enclosure in which the equipment resides
+ (ITU-T Recommendation X.733).
+ * QOS_ALARM: An alarm of this type is associated with degradation in
+ the
+ quality of a service (ITU-T Recommendation X.733).
+ * EQUIPMENT_ALARM: An alarm of this type is associated with an
+ equipment
+ fault (ITU-T Recommendation X.733).
+ type: string
+ enum:
+ - COMMUNICATIONS_ALARM
+ - PROCESSING_ERROR_ALARM
+ - ENVIRONMENTAL_ALARM
+ - QOS_ALARM
+ - EQUIPMENT_ALARM
+ faultType:
+ description: |
+ Additional information to clarify the type of the fault.
+ type: string
+ probableCause:
+ description: |
+ Information about the probable cause of the fault.
+ type: string
+ isRootCause:
+ description: >
+ Attribute indicating if this fault is the root for other correlated
+ alarms. If TRUE, then the alarms listed in the attribute
+ CorrelatedAlarmId are caused by this fault.
+ type: boolean
+ correlatedAlarmIds:
+ description: |
+ List of identifiers of other alarms correlated to this fault.
+ type: array
+ items:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ faultDetails:
+ description: |
+ Provides additional information about the fault.
+ type: array
+ items:
+ type: string
+ _links:
+ description: |
+ Links for this resource.
+ type: object
+ required:
+ - self
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ objectInstance:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ AlarmModifications:
+ description: >
+ This type represents attribute modifications for an "Individual alarm"
+ resource, i.e. modifications to a resource representation based on the
+ "Alarm" data type. The attributes of "Alarm" that can be modified are
+ included in the "AlarmModifications" data type.
+ type: object
+ required:
+ - ackState
+ properties:
+ ackState:
+ description: >
+ New value of the "ackState" attribute in "Alarm". Permitted values: *
+ ACKNOWLEDGED
+ type: string
+ enum:
+ - ACKNOWLEDGED
+ FmSubscription:
+ description: >
+ This type represents a subscription related to notifications about VNF
+ faults.
+ type: object
+ required:
+ - id
+ - callbackUri
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ filter:
+ description: >
+ This type represents a subscription filter related to notifications
+ about VNF faults. At a particular nesting level in the filter
+ structure, the following applies: All attributes shall match in order
+ for the filter to match (logical "and" between different filter
+ attributes). If an attribute is an array, the attribute shall match if
+ at least one of the values in the array matches (logical "or" between
+ the values of one filter attribute).
+ type: object
+ properties:
+ vnfInstanceSubscriptionFilter:
+ description: >
+ This type represents subscription filter criteria to match VNF
+ instances.
+ type: object
+ properties:
+ vnfdIds:
+ description: >
+ If present, match VNF instances that were created based on a
+ VNFD identified by one of the vnfdId values listed in this
+ attribute. The attributes "vnfdIds" and
+ "vnfProductsFromProviders" are alternatives to reference to
+ VNF instances that are based on certain VNFDs in a filter.
+ They should not be used both in the same filter instance, but
+ one alternative should be chosen.
+ type: array
+ items:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ vnfProductsFromProviders:
+ description: >
+ If present, match VNF instances that belong to VNF products
+ from certain providers. The attributes "vnfdIds" and
+ "vnfProductsFromProviders" are alternatives to reference to
+ VNF instances that are based on certain VNFDs in a filter.
+ They should not be used both in the same filter instance, but
+ one alternative should be chosen.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProvider
+ properties:
+ vnfProvider:
+ description: |
+ Name of the VNF provider to match.
+ type: string
+ vnfProducts:
+ description: >
+ If present, match VNF instances that belong to VNF
+ products with certain product names, from one particular
+ provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProductName
+ properties:
+ vnfProductName:
+ description: |
+ Name of the VNF product to match.
+ type: string
+ versions:
+ description: >
+ If present, match VNF instances that belong to VNF
+ products with certain versions and a certain
+ product name, from one particular provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfSoftwareVersion
+ properties:
+ vnfSoftwareVersion:
+ description: |
+ A version.
+ type: string
+ vnfdVersions:
+ description: >
+ If present, match VNF instances that belong
+ to VNF products with certain VNFD versions,
+ a certain software version and a certain
+ product name, from one particular provider.
+ type: array
+ items:
+ description: |
+ A version.
+ type: string
+ vnfInstanceIds:
+ description: >
+ If present, match VNF instances with an instance identifier
+ listed in this attribute. The attributes "vnfInstanceIds" and
+ "vnfInstanceNames" are alternatives to reference to particular
+ VNF Instances in a filter. They should not be used both in the
+ same filter instance, but one alternative should be chosen.
+ type: array
+ items:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ vnfInstanceNames:
+ description: >
+ If present, match VNF instances with a VNF Instance Name
+ listed in this attribute. The attributes "vnfInstanceIds" and
+ "vnfInstanceNames" are alternatives to reference to particular
+ VNF Instances in a filter. They should not be used both in the
+ same filter instance, but one alternative should be chosen.
+ type: array
+ items:
+ type: string
+ notificationTypes:
+ description: >
+ Match particular notification types. Permitted values: *
+ AlarmNotification * AlarmClearedNotification *
+ AlarmListRebuiltNotification The permitted values of the
+ "notificationTypes" attribute are spelled exactly as the names of
+ the notification types to facilitate automated code generation
+ systems.
+ type: array
+ items:
+ type: string
+ enum:
+ - AlarmNotification
+ - AlarmClearedNotification
+ - AlarmListRebuiltNotification
+ faultyResourceTypes:
+ description: >
+ Match VNF alarms with a faulty resource type listed in this
+ attribute.
+ type: array
+ items:
+ description: >
+ The enumeration FaultyResourceType represents those types of
+ faulty resource.
+ type: string
+ enum:
+ - COMPUTE
+ - STORAGE
+ - NETWORK
+ perceivedSeverities:
+ description: >
+ Match VNF alarms with a perceived severity listed in this
+ attribute.
+ type: array
+ items:
+ description: >
+ Indicates the relative level of urgency for operator attention.
+ * CRITICAL: The Critical severity level indicates that a service
+ affecting condition has occurred and an immediate corrective action
+ is required. Such a severity can be reported, for example, when a
+ managed object becomes totally out of service and its capability needs
+ to be restored (ITU-T Recommendation X.733).
+ * MAJOR: The Major severity level indicates that a service
+ affecting
+ condition has developed and an urgent corrective action is required.
+ Such a severity can be reported, for example, when there is a severe
+ degradation in the capability of the managed object and its full
+ capability needs to be restored (ITU-T Recommendation X.733).
+ * MINOR: The Minor severity level indicates the existence of a
+ non-service affecting fault condition and that corrective action
+ should be taken in order to prevent a more serious (for example,
+ service affecting) fault. Such a severity can be reported, for
+ example, when the detected alarm condition is not currently degrading
+ the capacity of the managed object (ITU-T Recommendation X.733).
+ * WARNING: The Warning severity level indicates the detection of
+ a
+ potential or impending service affecting fault, before any significant
+ effects have been felt. Action should be taken to further diagnose (if
+ necessary) and correct the problem in order to prevent it from
+ becoming a more serious service affecting fault (ITU-T Recommendation
+ X.733).
+ * INDETERMINATE: The Indeterminate severity level indicates that
+ the
+ severity level cannot be determined (ITU-T Recommendation X.733).
+ * CLEARED: The Cleared severity level indicates the clearing of
+ one or
+ more previously reported alarms. This alarm clears all alarms for this
+ managed object that have the same Alarm type, Probable cause and
+ Specific problems (if given) (ITU-T Recommendation X.733).
+ type: string
+ enum:
+ - CRITICAL
+ - MAJOR
+ - MINOR
+ - WARNING
+ - INDETERMINATE
+ - CLEARED
+ eventTypes:
+ description: |
+ Match VNF alarms with an event type listed in this attribute.
+ type: array
+ items:
+ description: >
+ The enumeration EventType represents those types of events that
+ trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type
+ is associated with the
+ procedure and/or process required conveying information from one point
+ to another (ITU-T Recommendation X.733).
+ * PROCESSING_ERROR_ALARM: An alarm of this type is associated
+ with a
+ software or processing fault (ITU-T Recommendation X.733).
+ * ENVIRONMENTAL_ALARM: An alarm of this type is associated with
+ a
+ condition related to an enclosure in which the equipment resides
+ (ITU-T Recommendation X.733).
+ * QOS_ALARM: An alarm of this type is associated with
+ degradation in the
+ quality of a service (ITU-T Recommendation X.733).
+ * EQUIPMENT_ALARM: An alarm of this type is associated with an
+ equipment
+ fault (ITU-T Recommendation X.733).
+ type: string
+ enum:
+ - COMMUNICATIONS_ALARM
+ - PROCESSING_ERROR_ALARM
+ - ENVIRONMENTAL_ALARM
+ - QOS_ALARM
+ - EQUIPMENT_ALARM
+ probableCauses:
+ description: |
+ Match VNF alarms with a probable cause listed in this attribute.
+ type: array
+ items:
+ type: string
+ callbackUri:
+ description: |
+ The URI of the endpoint to send the notification to.
+ type: string
+ format: url
+ _links:
+ description: |
+ Links for this resource.
+ type: object
+ required:
+ - self
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ FmSubscriptionRequest:
+ description: >
+ This type represents a subscription request related to notifications about
+ VNF faults.
+ type: object
+ required:
+ - callbackUri
+ properties:
+ filter:
+ description: >
+ This type represents a subscription filter related to notifications
+ about VNF faults. At a particular nesting level in the filter
+ structure, the following applies: All attributes shall match in order
+ for the filter to match (logical "and" between different filter
+ attributes). If an attribute is an array, the attribute shall match if
+ at least one of the values in the array matches (logical "or" between
+ the values of one filter attribute).
+ type: object
+ properties:
+ vnfInstanceSubscriptionFilter:
+ description: >
+ This type represents subscription filter criteria to match VNF
+ instances.
+ type: object
+ properties:
+ vnfdIds:
+ description: >
+ If present, match VNF instances that were created based on a
+ VNFD identified by one of the vnfdId values listed in this
+ attribute. The attributes "vnfdIds" and
+ "vnfProductsFromProviders" are alternatives to reference to
+ VNF instances that are based on certain VNFDs in a filter.
+ They should not be used both in the same filter instance, but
+ one alternative should be chosen.
+ type: array
+ items:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ vnfProductsFromProviders:
+ description: >
+ If present, match VNF instances that belong to VNF products
+ from certain providers. The attributes "vnfdIds" and
+ "vnfProductsFromProviders" are alternatives to reference to
+ VNF instances that are based on certain VNFDs in a filter.
+ They should not be used both in the same filter instance, but
+ one alternative should be chosen.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProvider
+ properties:
+ vnfProvider:
+ description: |
+ Name of the VNF provider to match.
+ type: string
+ vnfProducts:
+ description: >
+ If present, match VNF instances that belong to VNF
+ products with certain product names, from one particular
+ provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProductName
+ properties:
+ vnfProductName:
+ description: |
+ Name of the VNF product to match.
+ type: string
+ versions:
+ description: >
+ If present, match VNF instances that belong to VNF
+ products with certain versions and a certain
+ product name, from one particular provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfSoftwareVersion
+ properties:
+ vnfSoftwareVersion:
+ description: |
+ A version.
+ type: string
+ vnfdVersions:
+ description: >
+ If present, match VNF instances that belong
+ to VNF products with certain VNFD versions,
+ a certain software version and a certain
+ product name, from one particular provider.
+ type: array
+ items:
+ description: |
+ A version.
+ type: string
+ vnfInstanceIds:
+ description: >
+ If present, match VNF instances with an instance identifier
+ listed in this attribute. The attributes "vnfInstanceIds" and
+ "vnfInstanceNames" are alternatives to reference to particular
+ VNF Instances in a filter. They should not be used both in the
+ same filter instance, but one alternative should be chosen.
+ type: array
+ items:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ vnfInstanceNames:
+ description: >
+ If present, match VNF instances with a VNF Instance Name
+ listed in this attribute. The attributes "vnfInstanceIds" and
+ "vnfInstanceNames" are alternatives to reference to particular
+ VNF Instances in a filter. They should not be used both in the
+ same filter instance, but one alternative should be chosen.
+ type: array
+ items:
+ type: string
+ notificationTypes:
+ description: >
+ Match particular notification types. Permitted values: *
+ AlarmNotification * AlarmClearedNotification *
+ AlarmListRebuiltNotification The permitted values of the
+ "notificationTypes" attribute are spelled exactly as the names of
+ the notification types to facilitate automated code generation
+ systems.
+ type: array
+ items:
+ type: string
+ enum:
+ - AlarmNotification
+ - AlarmClearedNotification
+ - AlarmListRebuiltNotification
+ faultyResourceTypes:
+ description: >
+ Match VNF alarms with a faulty resource type listed in this
+ attribute.
+ type: array
+ items:
+ description: >
+ The enumeration FaultyResourceType represents those types of
+ faulty resource.
+ type: string
+ enum:
+ - COMPUTE
+ - STORAGE
+ - NETWORK
+ perceivedSeverities:
+ description: >
+ Match VNF alarms with a perceived severity listed in this
+ attribute.
+ type: array
+ items:
+ description: >
+ Indicates the relative level of urgency for operator attention.
+ * CRITICAL: The Critical severity level indicates that a service
+ affecting condition has occurred and an immediate corrective action
+ is required. Such a severity can be reported, for example, when a
+ managed object becomes totally out of service and its capability needs
+ to be restored (ITU-T Recommendation X.733).
+ * MAJOR: The Major severity level indicates that a service
+ affecting
+ condition has developed and an urgent corrective action is required.
+ Such a severity can be reported, for example, when there is a severe
+ degradation in the capability of the managed object and its full
+ capability needs to be restored (ITU-T Recommendation X.733).
+ * MINOR: The Minor severity level indicates the existence of a
+ non-service affecting fault condition and that corrective action
+ should be taken in order to prevent a more serious (for example,
+ service affecting) fault. Such a severity can be reported, for
+ example, when the detected alarm condition is not currently degrading
+ the capacity of the managed object (ITU-T Recommendation X.733).
+ * WARNING: The Warning severity level indicates the detection of
+ a
+ potential or impending service affecting fault, before any significant
+ effects have been felt. Action should be taken to further diagnose (if
+ necessary) and correct the problem in order to prevent it from
+ becoming a more serious service affecting fault (ITU-T Recommendation
+ X.733).
+ * INDETERMINATE: The Indeterminate severity level indicates that
+ the
+ severity level cannot be determined (ITU-T Recommendation X.733).
+ * CLEARED: The Cleared severity level indicates the clearing of
+ one or
+ more previously reported alarms. This alarm clears all alarms for this
+ managed object that have the same Alarm type, Probable cause and
+ Specific problems (if given) (ITU-T Recommendation X.733).
+ type: string
+ enum:
+ - CRITICAL
+ - MAJOR
+ - MINOR
+ - WARNING
+ - INDETERMINATE
+ - CLEARED
+ eventTypes:
+ description: |
+ Match VNF alarms with an event type listed in this attribute.
+ type: array
+ items:
+ description: >
+ The enumeration EventType represents those types of events that
+ trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type
+ is associated with the
+ procedure and/or process required conveying information from one point
+ to another (ITU-T Recommendation X.733).
+ * PROCESSING_ERROR_ALARM: An alarm of this type is associated
+ with a
+ software or processing fault (ITU-T Recommendation X.733).
+ * ENVIRONMENTAL_ALARM: An alarm of this type is associated with
+ a
+ condition related to an enclosure in which the equipment resides
+ (ITU-T Recommendation X.733).
+ * QOS_ALARM: An alarm of this type is associated with
+ degradation in the
+ quality of a service (ITU-T Recommendation X.733).
+ * EQUIPMENT_ALARM: An alarm of this type is associated with an
+ equipment
+ fault (ITU-T Recommendation X.733).
+ type: string
+ enum:
+ - COMMUNICATIONS_ALARM
+ - PROCESSING_ERROR_ALARM
+ - ENVIRONMENTAL_ALARM
+ - QOS_ALARM
+ - EQUIPMENT_ALARM
+ probableCauses:
+ description: |
+ Match VNF alarms with a probable cause listed in this attribute.
+ type: array
+ items:
+ type: string
+ callbackUri:
+ description: |
+ The URI of the endpoint to send the notification to.
+ type: string
+ format: url
+ authentication:
+ type: object
+ required:
+ - authType
+ properties:
+ authType:
+ description: >
+ Defines the types of Authentication / Authorization which the API
+ consumer is willing to accept when receiving a notification.
+ Permitted values: * BASIC: In every HTTP request to the
+ notification endpoint, use
+ HTTP Basic authentication with the client credentials.
+ * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the
+ notification endpoint, use an OAuth 2.0 Bearer token, obtained
+ using the client credentials grant type.
+ * TLS_CERT: Every HTTP request to the notification endpoint is
+ sent
+ over a mutually authenticated TLS session, i.e. not only the
+ server is authenticated, but also the client is authenticated
+ during the TLS tunnel setup.
+ type: array
+ items:
+ type: string
+ enum:
+ - BASIC
+ - OAUTH2_CLIENT_CREDENTIALS
+ - TLS_CERT
+ paramsBasic:
+ description: >
+ Parameters for authentication/authorization using BASIC. Shall be
+ present if authType is "BASIC" and the contained information has
+ not been provisioned out of band. Shall be absent otherwise.
+ type: object
+ properties:
+ userName:
+ description: >
+ Username to be used in HTTP Basic authentication. Shall be
+ present if it has not been provisioned out of band.
+ type: string
+ password:
+ description: >
+ Password to be used in HTTP Basic authentication. Shall be
+ present if it has not been provisioned out of band.
+ type: string
+ paramsOauth2ClientCredentials:
+ description: >
+ Parameters for authentication/authorization using
+ OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is
+ "OAUTH2_CLIENT_CREDENTIALS" and the contained information has not
+ been provisioned out of band. Shall be absent otherwise.
+ type: object
+ properties:
+ clientId:
+ description: >
+ Client identifier to be used in the access token request of
+ the OAuth 2.0 client credentials grant type. Shall be present
+ if it has not been provisioned out of band. The clientId and
+ clientPassword passed in a subscription shall not be the same
+ as the clientId and clientPassword that are used to obtain
+ authorization for API requests. Client credentials may differ
+ between subscriptions. The value of clientPassword should be
+ generated by a random process.
+ type: string
+ clientPassword:
+ description: >
+ Client password to be used in the access token request of the
+ OAuth 2.0 client credentials grant type. Shall be present if
+ it has not been provisioned out of band. The clientId and
+ clientPassword passed in a subscription shall not be the same
+ as the clientId and clientPassword that are used to obtain
+ authorization for API requests. Client credentials may differ
+ between subscriptions. The value of clientPassword should be
+ generated by a random process.
+ type: string
+ tokenEndpoint:
+ description: |
+ String formatted according to IETF RFC 3986.
+ type: string
+
diff --git a/SOL003/VNFFaultManagement-API_egm/jsons/alarmModifications.json b/SOL003/VNFFaultManagement-API_egm/jsons/alarmModifications.json
new file mode 100644
index 0000000000000000000000000000000000000000..53121e5b7d04ebd9c2c9c9f93e676aaa6ecefb86
--- /dev/null
+++ b/SOL003/VNFFaultManagement-API_egm/jsons/alarmModifications.json
@@ -0,0 +1,3 @@
+{
+ "ackState": "ACKNOWLEDGED"
+}
\ No newline at end of file
diff --git a/SOL003/VNFFaultManagement-API_egm/variables.txt b/SOL003/VNFFaultManagement-API_egm/variables.txt
new file mode 100644
index 0000000000000000000000000000000000000000..3facdfff048d62215d14763eadef379b50d12f49
--- /dev/null
+++ b/SOL003/VNFFaultManagement-API_egm/variables.txt
@@ -0,0 +1,40 @@
+*** Variables ***
+${VNFM_HOST} localhost # Hostname of the VNFM
+${VNFM_PORT} 8080 # Listening port of the VNFM
+${NFVO_HOST} localhost # Hostname of the NFVO
+${NFVO_PORT} 8081 # Listening port of the NFVO
+${VNFM_SCHEMA} https
+${NFVO_SCHEMA} https
+${AUTHORIZATION} Bearer QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+${CONTENT_TYPE} application/json
+${CONTENT_TYPE_PATCH} application/merge-patch+json
+${ACCEPT} application/json
+${apiRoot} /
+${apiName} vnffm
+${apiVersion} v1
+${AUTH_USAGE} 1
+${WRONG_AUTHORIZATION} Bearer XXXXXWRONGXXXXX
+${alarm_filter} managedObjectId
+${managedObjectId} 007c111c-38a1-42c0-a666-7475ecb1567c
+${invalid_alarm_filter} badFilter
+${alarmId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d
+${vnfInstanceDescription} description vnf
+${vnfInstanceDescription_Update} Updated description vnf
+${SINGLE_FILE_VNFD} 1 # If VNFD is PLAIN TEXT
+${ACCEPT_PLAIN} text/plain
+${ACCEPT_ZIP} application/zip
+${vnfPkgId_processing} 007c111c-38a1-42c0-a666-7475ecb1567c
+${ARTIFACT_TYPE} application/octet-stream
+${ARTIFACT_ID} artifactId
+${WRONG_ACCEPT} application/json
+${vnfLcmOpOccId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d
+${CancelMode} GRACEFUL
+${LccnSubscriptionRequest} {}
+${NVFM_DUPLICATION} 0
+${sub_filter} filter
+${sub_filter_invalid} filter_invalid
+${subscriptionId} 6fc3539c-e602-4afa-8e13-962fb5a7d81f
+${notification_ep} notification
+${VnfLcmOperationOccurrenceNotification} {}
+${VnfIdentifierCreationNotification} {}
+${VnfIdentifierDeletionNotification} {}
\ No newline at end of file
diff --git a/TrackingStatus.txt b/TrackingStatus.txt
index 0f8e46030057ecd8cffd44a92d9ece6de2f186ed..ad81e23fccb0e3e605112ad428161316e8ab5fc2 100644
--- a/TrackingStatus.txt
+++ b/TrackingStatus.txt
@@ -28,7 +28,11 @@ SOL003
- VirtualisedResourcesQuotaAvailableNotification-API_egm --> [NOT STARTED]
- - VNFFaultManagement-API_egm ------------------------------> [NOT STARTED]
+ - VNFFaultManagement-API_egm ------------------------------> [IN PROGRESS]
+ * Alarms ----------------------------------------------> [DONE]
+ * IndividualAlarm ----------------------------------------------> [DONE]
+ * Subscriptions --------------------------------------------> [IN PROGRESS] //to be reviewed with nxw on how notification server will be configured
+ * IndividualSubscription -----------------------------------> [IN PROGRESS]
- VNFFaultManagementNotification-API_egm ------------------> [NOT STARTED]