{"openapi":"3.0.2","info":{"title":"SOL009 - NFV-MANO Configuration and Information Management Interface","description":"SOL009 - NFV-MANO Configuration and Information Management Interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL009/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.0.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 009 V3.5.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/009/03.05.01_60/gs_NFV-SOL009v030501p.pdf"},"servers":[{"url":"http://127.0.0.1/nfvmanocim/v2"},{"url":"https://127.0.0.1/nfvmanocim/v2"}],"paths":{"/api_versions":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in table 4.6.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"200 OK\nAPI version information was read successfully. The response body shall contain 4.4 API version information, as defined in clause 4.4.1.13.\n","content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}},"headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the payload body of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"416":{"description":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"patch":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/mano_entity":{"get":{"description":"The GET method retrieves information about an NFV-MANO functional entity by reading the NFV-MANO entity resource. See clause 5.5.3.3.2.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when configuration and information about  the NFV-MANO functional entity has been read successfully. The response body shall contain a representation of the NFV-MANO functional entity, as defined in clause 5.6.2.2.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an NFV-MANO functional entity. *  NOTE 1:\tIt shall be present when \"type\" attribute is \"NFVO\", and it shall be absent in any other case. *  NOTE 2:\tIt shall be present when \"type\" attribute is \"VNFM\", and it shall be absent in any other case. *  NOTE 3:\tIt shall be present when \"type\" attribute is \"VIM\", and it shall be absent in any other case. *  NOTE 4:\tThe information about the NFV-MANO services offered by a specific type of NFV-MANO functional\n            entity is specified by the manoServices attribute.\n*  NOTE 5:\tIt is optional for the API producer to support the \"manoEntityComponents\" attribute. *  NOTE 6:\tIt shall be present when \"type\" attribute is \"WIM\", and it shall be absent in any other case.\n","type":"object","required":["id","type","name","description","provider","softwareVersion","manoConfigurableParams","manoApplicationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"type":{"description":"The enumeration ManoEntityEnumType defines the permitted values to  represent NFV-MANO functional entities. It shall comply with  the provisions :\n  - NFVO\tThe NFV-MANO functional entity is an NFVO.\n  - VNFM\tThe NFV-MANO functional entity is a VNFM.\n  - VIM\t    The NFV-MANO functional entity is a VIM.\n  - WIM     The NFV-MANO functional entity is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM"]},"name":{"description":"Human-readable name of the NFV-MANO functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"description":{"description":"Human-readable description of the NFV-MANO functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"provider":{"description":"Information about the provider of the NFV-MANO functional entity.  It typically includes the name of the provider.\n","type":"string"},"softwareVersion":{"description":"A version.\n","type":"string"},"manoEntityComponents":{"description":"The deployed NFV-MANO functional entity components which realize the  NFV-MANO functional entity. See note 5.\n","type":"array","items":{"description":"This type represents information of a deployed component realizing part of an  NFV-MANO functional entity. It is optional for the API producer to support  this type.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"manoServiceIds":{"description":"References to the NFV-MANO services that depend on the NFV-MANO functional  entity component. The identifier of the ManoService is referred. A service  may depend on multiple components. Multiple services may depend on the same  component.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}}}}},"manoServices":{"description":"Information about the NFV-MANO services provided by the NFV-MANO  functional entity.\n","type":"array","items":{"description":"This type represents information about an NFV-MANO service provided by the  NFV-MANO functional entity. * NOTE:\tA cardinality greater than one supports having different interface versions or api Endpoints\n        to be used for accessing the same instance of an NFV-MANO service.\n","type":"object","properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO service.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"description":{"description":"Human-readable description of the NFV-MANO service.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"manoServiceInterfaceIds":{"description":"Reference to the NFV-MANO interfaces associated to the NFV-MANO service.  If cardinality is greater than one, the type of ManoServiceInterface  (see clause 5.6.3.3) shall be the same. The identifier of the  ManoServiceInterface is referred. See note\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"minItems":1},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"manoServiceInterfaces":{"description":"Link to the \"individual NFV-MANO service interface\" resources with  information about the associated interfaces to the NFV-MANO service.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"minItems":1}},"required":["manoServiceInterfaces"]}},"required":["id","name","description","manoServiceInterfaceIds","_links"]}},"manoConfigurableParams":{"description":"ManoConfigurableParams\n"},"manoApplicationState":{"description":"Information and current values of the NFV-MANO functional entity’s application state.\n","type":"object","required":["operationalState","administrativeState","usageState"],"properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]},"usageState":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]}}},"nfvoSpecificInfo":{"description":"This type represents information attributes specific to an NFVO entity,  and that can be relevant to more than one NFV-MANO service offered by an NFVO entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and version\n            of the specification. For instance, \"ETSI GS NFV-SOL 001 (V2.5.1)\".\n  NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined.\n","type":"object","properties":{"maxOnboardedNsdNum":{"description":"Maximum number of NSDs that can be on-boarded on the NFVO. See note 2.\n","type":"integer"},"maxOnboardedVnfPkgNum":{"description":"Maximum number of VNF Packages that can be on-boarded on the NFVO. See note 2.\n","type":"integer"},"supportedVnfdFormats":{"description":"Supported VNFD data formats.\n","type":"object","properties":{"vnfdFormat":{"description":"Name of the VNFD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["vnfdFormat","standardVersion"]},"supportedNsdFormats":{"description":"Supported NSD data formats.\n","type":"object","properties":{"nsdFormat":{"description":"Name of the NSD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["nsdFormat","standardVersion"]}},"required":["supportedVnfdFormats","supportedNsdFormats"]},"vnfmSpecificInfo":{"description":"This type represents information attributes specific to a VNFM entity,  and that can be relevant to more than one NFV-MANO service offered by a VNFM entity. * NOTE:\tThe information to be provided in this attribute shall relate to the specification and version\n        of the specification. For instance, \"ETSI GS NFV-SOL 001 (V2.5.1)\".\n","type":"object","properties":{"resoruceMgmtModeSupport":{"description":"The supported resource management modes of the VNFM.\nPermitted values:\n  - DIRECT: The VNFM supports direct mode only.\n  - INDIRECT: The VNFM supports indirect mode only.\n  - BOTH: The VNFM supports both direct and indirect mode.\n","type":"string","enum":["DIRECT","INDIRECT","BOTH"]},"managedVnfInstanceInfos":{"description":"The kinds of VNF instances that can be managed, e.g. to determine the  compatibility of a VNF with certain VNFM according to the vnfmInfo  attribute in the VNFD (see table 7.1.2.2-1 in ETSI GS NFV-IFA 011).\n","type":"array","items":{"type":"string"},"minItems":1},"supportedVnfdFormats":{"description":"Supported VNFD data formats.\n","type":"array","items":{"type":"object","properties":{"vnfdFormat":{"description":"Name of the VNFD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["vnfdFormat","standardVersion"]},"minItems":1}},"required":["resoruceMgmtModeSupport","managedVnfInstanceInfos","supportedVnfdFormats"]},"vimSpecificInfo":{"description":"This type represents information attributes specific to a VIM entity,  and that can be relevant to more than one NFV-MANO service offered by  a VIM entity.\n","type":"object"},"wimSpecificInfo":{"description":"This type represents information attributes specific to a WIM entity, and that can be relevant to more than one NFV MANO service offered by a WIM entity.\n","type":"object","required":["maxMscsNums","maxMsncNum","mscsLayerProtocolSupport"],"properties":{"maxMscsNums":{"description":"Maximum number of MSCS that the WIM can manage.\n","type":"object","required":["numMscs"],"properties":{"numMscs":{"description":"Maximum number of MSCS.\n","type":"integer"},"criteriaNumMscs":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"maxMsncNum":{"description":"Maximum number of MSNC that the WIM can manage\n","type":"object","required":["numMsnc"],"properties":{"numMsnc":{"description":"Maximum number of MSNC..\n","type":"integer"},"criteriaNumMsnc":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"mscsLayerProtocolSupport":{"description":"List of protocols of particular layers used to realize an MSCS that are supported by the WIM.\nPermitted values:  - EVPN_BGP_MPLS: L2 MSCS realized by BGP MPLS-based Ethernet VPN (EVPN) as specified in IETF RFC 7432.\n  - EVPN_VPWS: L2 MSCS realized by EVPN Virtual Private Wire Service (VPWS) as specified in IETF RFC 8214.\n  - VPLS_BGP: L2 MSCS realized by Virtual Private LAN Service (VPLS) using BGP as specified\n    in IETF RFC 4761 and IETF RFC.\n  - VPLS_LDP_L2TP: L2 MSCS realized by VPLS using Label Distribution Protocol (LDP) Layer 2\n    Tunnelling Protocol (L2TP) as specified in IETF RFC 4762 and IETF RFC 6074.\n  - VPWS_LDP_L2TP: L2 MSCS realized by VPWS using LDP L2TP as specified in IETF RFC 6074.\n  - BGP_IP_VPN: L3 MSCS realized by BGP/MPLS based IP VPN as specified in IETF RFC 4364.\n","type":"string","enum":["EVPN_BGP_MPLS","EVPN_VPWS","VPLS_BGP","VPLS_LDP_L2TP","VPWS_LDP_L2TP","BGP_IP_VPN"]}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","manoServiceInterfaces","peerEntities","changeState","changeStateOpOccs"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"manoServiceInterfaces":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"peerEntities":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeState":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeStateOpOccs":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"patch":{"description":"The PATCH method modifies the NFV-MANO entity resource. See clause 5.5.3.3.4.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"requestBody":{"description":"Parameters for the NFV-MANO configuration and information  modification, as defined in clause 5.6.2.3. The Content-Type header shall be set to \"application/merge-patch+json\"  according to IETF RFC 7396.\n","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for configuration parameters  of an NFV-MANO functional entity. * NOTE:\tAt least one of these attributes shall be provided if requesting a modification\n        of the NFV-MANO service identified by \"id\".\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"ManoEntity\".\n","type":"string"},"description":{"description":"New value of the \"description\" attribute in \"ManoEntity\".\n","type":"string"},"clockSyncs":{"description":"Modifications of the \"clockSyncs\" attribute in the \"ManoEntityConfigurableParams\". If present, these modifications shall be applied according to the rules of JSON Merge PATCH (see IETF RFC 7396).\n","type":"object","additionalProperties":{"description":"This type represents parameters for connecting to an NTP server. * NOTE:\tEither ipAddress or hostname shall be set, but not both at the same time.\n","type":"object","properties":{"type":{"description":"Type of clock synchronization.\nPermitted values:\n  - NTP: For Network Time Protocol (NTP) based clock synchronization.\n  - OTHER: For other types of clock synchronization.\n","type":"string","enum":["NTP","OTHER"]},"ntpServerInfo":{"description":"Information for the NTP based clock synchronization. Shall be present if type = \"NTP\".\n","type":"object","properties":{"ipAddress":{"description":"An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n","type":"string","format":"IP"},"hostname":{"description":"Indicates the hostname of the NTP server. See note.\n","type":"string"}}},"otherClockSyncParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"required":["type"]}},"defaultLogCompileBySizeValue":{"description":"Unsigned integer\n","type":"number"},"defaultLogCompileByTimerValue":{"description":"Unsigned integer\n","type":"number"},"manoServiceModifications":{"description":"New content of certain entries in the \"manoServices\" attribute array  in the \"ManoEntity\", as defined below this table. The following provisions shall apply when modifying an attribute that is an array of structured \"manoServiceModifications\". Assumptions:\n  A)\t\"oldList\" is the array to be modified, \"newList\" is the array that contains the changes.\n  B)\t\"oldEntry\" is an entry in \"oldList\" and \"newEntry\" is an entry in \"newList\".\n  C)\tA \"newEntry\" has a \"corresponding entry\" if there exists an \"oldEntry\" that has the same\n        content of \"id\" attribute as the \"newEntry\".\n  D)\tIn any array of objects, the content of \"id\" is unique (i.e. there are no two entries\n        with the same content of \"id\").\nProvisions:\n  1)\tFor each \"newEntry\" in \"newList\" that has a corresponding \"oldEntry\" in \"oldList\", the values of\n        the sub-attributes of \"oldEntry\" shall be replaced by the value of the sub-attributes in the \"newEntry\".\n  2)\tIf the \"newEntry\" in \"newList\" has no corresponding \"oldEntry\" in \"oldList\" (i.e. the \"id\" is\n        not found), the modification operation will fail as a whole and an error message shall be raised.\n","type":"array","items":{"type":"object","required":["id"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"New value for the \"name\" attribute in the \"ManoService\". See note.\n","type":"string"},"description":{"description":"New value for the \"description\" attribute in the \"ManoService\". See note.\n","type":"string"}}}}}}}},"required":true},"responses":{"200":{"description":"200 OK\nShall be returned when the modification of configuration on the  NFV-MANO functional entity has been accepted and completed.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications that were performed on the  \"NFV-MANO entity\" resource of the producer NFV-MANO functional entity.  The attributes that can be included consist of those requested to be  modified explicitly in the \"ManoConfigModificationRequest\" data structure.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\"  attribute in \"ManoEntity\", as defined in clause 5.6.2.3\n","type":"string"},"description":{"description":"If present, this attribute signals modifications of the \"description\"  attribute in \"ManoEntity\", as defined in clause 5.6.2.3.\n","type":"string"},"clockSyncs":{"description":"If present, this attribute signals modifications of the \"clockSyncs\" attribute in \"ManoEntityConfigurableParams\", as defined in clause 5.6.2.3.\n","type":"object","additionalProperties":{"description":"This type represents parameters for connecting to an NTP server. * NOTE:\tEither ipAddress or hostname shall be set, but not both at the same time.\n","type":"object","properties":{"type":{"description":"Type of clock synchronization.\nPermitted values:\n  - NTP: For Network Time Protocol (NTP) based clock synchronization.\n  - OTHER: For other types of clock synchronization.\n","type":"string","enum":["NTP","OTHER"]},"ntpServerInfo":{"description":"Information for the NTP based clock synchronization. Shall be present if type = \"NTP\".\n","type":"object","properties":{"ipAddress":{"description":"An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n","type":"string","format":"IP"},"hostname":{"description":"Indicates the hostname of the NTP server. See note.\n","type":"string"}}},"otherClockSyncParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"required":["type"]}},"defaultLogCompileBySizeValue":{"description":"Unsigned integer\n","type":"number"},"defaultLogCompileByTimerValue":{"description":"Unsigned integer\n","type":"number"},"manoServiceModifications":{"description":"If present, this attribute signals modifications of the \"manoServices\"  attribute array in the \"ManoEntity\", as defined in clause 5.6.2.3.\n","type":"array","items":{"type":"object","properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"If present, this attribute signals modification of the \"name\"  attribute in the \"ManoService\".\n","type":"string"},"description":{"description":"If present, this attribute signals modification of the  \"description\" attribute in the \"ManoService\".\n","type":"string"}},"required":["id"]}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot  be executed currently, due to a conflict with the state of the  \"NFV-MANO entity\" resource.\nTypically, this is due to the fact that another configuration and  information modification is ongoing.\nThe response body shall contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"412":{"description":"412 PRECONDITION FAILED\nShall be returned upon the following error: A precondition given in  an HTTP request header is not fulfilled.\nTypically, this is due to an ETag mismatch, indicating that the resource  was modified by another entity.\nThe response body should contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/mano_entity/change_state":{"post":{"description":"The POST method requests to change the state of the NFV-MANO functional entity application. See clause 5.5.7.3.1.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"requestBody":{"description":"Parameters for the change state operation, as defined in clause 5.6.2.8.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for changing the state of a managed entity. * NOTE 1:\tIn the present document version, a request shall only include an operational state change\n            (attribute \"operationalStateChange\") or an administrative state change request (attribute\n            \"administrativeStateChange\"), but not both.\n* NOTE 2:\tThe \"stopType\" shall only be provided when the \"operationalStateAction\" attribute is equal\n            to \"STOP\" or \"RESTART\". The \"gracefulStopTimeout\" shall be absent when the \"stopType\" attribute\n            is equal to \"FORCEFUL\", and may be provided otherwise.\n","type":"object","properties":{"operationalStateChange":{"description":"A change of operational state. Shall be present if the state change request refers to the operational state. See note 1. but not both.\n","type":"object","properties":{"operationalStateAction":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"stopType":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values  for the change state operation. It shall comply with the provisions:\n  - GRACEFUL\tTo stop the managed entity immediately after accepting the request.\n  - FORCEFUL\tTo stop the managed entity attempting to gracefully discharge the entity from service.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"gracefulStopTimeout":{"description":"The time internal (in seconds) to wait for the entity to be taken out  of service during graceful stop. See note 2.\n","type":"integer"}},"required":["operationalStateAction"]},"administrativeStateChange":{"description":"A change of administrative state. Shall be present if the state change request refers to the administrative state. See note 1. but not both.\n","type":"object","required":["administrativeStateAction"],"properties":{"administrativeStateAction":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]}}}}}}},"required":true},"responses":{"202":{"description":"202 ACCEPTED\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that contains  the URI of the newly-created \"Individual change state operation occurrence\" resource corresponding to the operation.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual change state operation occurence\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot be  executed currently, due to a conflict with the state of the resource.\nTypically, this is due to the fact that the resource is in an incompatible  state, or that another change state operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which the  \"detail\" attribute shall convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/mano_entity/mano_interfaces":{"get":{"description":"The GET method queries information about multiple NFV-MANO service interfaces of the NFV-MANO functional entity. See clause 5.5.10.3.2.\n","parameters":[{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of  ETSI GS NFV-SOL 013.\nThe NFV-MANO functional entity shall support receiving this parameter  as part of the URI query string. The API consumer may supply this  parameter.\nAll attribute names that appear in the ManoServiceInterface and in data  types referenced from it shall be supported by the NFV-MANO functional  entity in the expression.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"all_fields","description":"Include all complex attributes in the response. See clause  5.3 of ETSI GS NFV-SOL 013. The NFV-MANO functional entity  shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause  5.3 of ETSI GS NFV-SOL 013 for details. The NFV-MANO functional  entity should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause  5.3 of ETSI GS NFV-SOL 013 for details. The NFV-MANO functional  entity should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_default","description":"Indicates to exclude the following complex attributes from the  response. See clause 5.3 of ETSI GS NFV-SOL 013 for details.  The NFV-MANO functional entity shall support this parameter.\nThe following attributes shall be excluded from the ManoServiceInterface  structure in the response body if this parameter is provided, or none of  the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\"  are provided: - none\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by  the NFV-MANO functional entity if the entity supports alternative 2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when information about zero or more NFV-MANO  service interfaces has been queried successfully.\nThe response body shall contain in an array the representations  of zero or more NFV-MANO service interfaces, as defined in  clause 5.6.2.11.\nIf the “filter\" URI parameter or one of the \"all_fields\", \"fields\"  (if supported), \"exclude_fields\" (if supported) or \"exclude_default\"  URI parameters was supplied in the request, the data in the response  body shall have been transformed according to the rules specified in  clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively.\nIf the NFV-MANO functional entity supports alternative N°2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,  inclusion of the Link HTTP header in this response shall follow the  provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Link HTTP header in this response  shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","schema":{"type":"string","minimum":0,"maximum":1}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents an individual NFV-MANO service interface produced by  an NFV-MANO functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and\n            version of the specification. For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined. Overload is\n            handled by the error handling schemes defined by the applicable API specification.\n* NOTE 3:\tDue to the security sensitive information associated to the attribute, based on access\n            control policies, the API consumer might have read only, write only, read/write, or no access\n            at all to the attribute's value. In case the API consumer is not allowed to read the value of\n            the security sensitive attribute, the attribute shall be omitted when the information is to be\n            provided in a response message, and shall be provided otherwise. In case the API consumer is\n            not allowed to modify the value of the security sensitive attribute, and the modification request\n            includes new attribute values, the whole modification request shall be rejected, and proper\n            error information returned.\n","type":"object","required":["id","name","type","standardVersion","providerSpecificApiVersion","apiVersion","apiEndpoint","supportedOperations","interfaceState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO functional entity interface.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface produced by the NFV-MANO functional  entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"providerSpecificApiVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Exposed API endpoint of the interface.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1 of  ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"maxConcurrentIntOpNumber":{"description":"Maximum number of concurrent operation requests supported on this interface. See note 2.\n","type":"integer"},"supportedOperations":{"description":"Information about supported operations of this interface.\n","type":"array","items":{"type":"object","properties":{"operationName":{"description":"Name of the operation supported on the interface.\n","type":"string"},"maxConcurrentOpNumber":{"description":"Maximum number of concurrent requests supported by the interface operation. See note 2.\n","type":"integer"}},"required":["operationName"]},"minItems":1},"interfaceState":{"description":"State of the NFV-MANO service interface.\n","properties":{"operationalState":{"description":"The enumeration InterfaceOperationalStateEnumType defines values representing  the operational state of an NFV-MANO service interface type of managed entity.  The InterfaceOperationalStateEnumType shall comply with the provisions :\n   - STARTED\tThe managed entity is operational.\n   - STOPPED\tThe managed entity is not operational.\n   - STOPPING\tThe managed entity is in the transition to stop.\n   - STARTING\tThe managed entity is in the transition to start and become operational.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]},"usageState":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]}},"required":["operationalState","administrativeState","usageState"]},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}}},"400":{"description":"400 BAD REQUEST\nShall be returned upon the following errors: \n  - Invalid attribute-based filtering expression.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Invalid attribute selector.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Response too big.\n    If the NFV-MANO functional entity supports alternative N°1 (error) \n    according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, \n    this error response shall follow the provisions in clause 5.4.2.2 of \n    ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/mano_entity/mano_interfaces/{manoServiceInterfaceId}":{"parameters":[{"name":"manoServiceInterfaceId","in":"path","description":"Identifier of the MANO service interface.","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}],"get":{"description":"The GET method retrieves information about an NFV-MANO service interface of the producer NFV-MANO functional entity by reading an \"Individual NFV-MANO service interface\" resource. See clause 5.5.11.3.2.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when information about an individual NFV-MANO  service interface has been read successfully.\nThe response body shall contain a representation of the NFV-MANO  service interface, as defined in clause 5.6.2.11.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an individual NFV-MANO service interface produced by  an NFV-MANO functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and\n            version of the specification. For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined. Overload is\n            handled by the error handling schemes defined by the applicable API specification.\n* NOTE 3:\tDue to the security sensitive information associated to the attribute, based on access\n            control policies, the API consumer might have read only, write only, read/write, or no access\n            at all to the attribute's value. In case the API consumer is not allowed to read the value of\n            the security sensitive attribute, the attribute shall be omitted when the information is to be\n            provided in a response message, and shall be provided otherwise. In case the API consumer is\n            not allowed to modify the value of the security sensitive attribute, and the modification request\n            includes new attribute values, the whole modification request shall be rejected, and proper\n            error information returned.\n","type":"object","required":["id","name","type","standardVersion","providerSpecificApiVersion","apiVersion","apiEndpoint","supportedOperations","interfaceState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO functional entity interface.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface produced by the NFV-MANO functional  entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"providerSpecificApiVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Exposed API endpoint of the interface.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1 of  ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"maxConcurrentIntOpNumber":{"description":"Maximum number of concurrent operation requests supported on this interface. See note 2.\n","type":"integer"},"supportedOperations":{"description":"Information about supported operations of this interface.\n","type":"array","items":{"type":"object","properties":{"operationName":{"description":"Name of the operation supported on the interface.\n","type":"string"},"maxConcurrentOpNumber":{"description":"Maximum number of concurrent requests supported by the interface operation. See note 2.\n","type":"integer"}},"required":["operationName"]},"minItems":1},"interfaceState":{"description":"State of the NFV-MANO service interface.\n","properties":{"operationalState":{"description":"The enumeration InterfaceOperationalStateEnumType defines values representing  the operational state of an NFV-MANO service interface type of managed entity.  The InterfaceOperationalStateEnumType shall comply with the provisions :\n   - STARTED\tThe managed entity is operational.\n   - STOPPED\tThe managed entity is not operational.\n   - STOPPING\tThe managed entity is in the transition to stop.\n   - STARTING\tThe managed entity is in the transition to start and become operational.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]},"usageState":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]}},"required":["operationalState","administrativeState","usageState"]},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"patch":{"description":"This method is used to modify an \"Individual NFV-MANO service interface\" resource. See clause 5.5.11.3.4.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"requestBody":{"description":"Parameters for the modification of configuration parameters of  the NFV-MANO service interface, as defined in clause 5.6.2.12.\nThe Content-Type header shall be set to \"application/merge-patch+json\" according to IETF RFC 7396.\n","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for configuration parameters of  an NFV-MANO service interface of the producer NFV-MANO functional entity. * NOTE 1:\tChanging the name does not change the corresponding standardized API name in the resource URI\n            (refer to \"{apiName}\" defined in clause 4.1 of ETSI GS NFV-SOL 013).\n* NOTE 2:\tThe change of apiRoot or apiUri on an enabled and in use API may be service disruptive. Also,\n            that change invalidates any related URI that might have been cached at API consumers.\n* NOTE 3:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all\n            to the attribute's value. In case the API consumer is not allowed to modify the value of the\n            security sensitive attribute, and the modification request includes new attribute values,\n            the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"ManoServiceInterface\". See note 1.\n","type":"string"},"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"responses":{"200":{"description":"200 OK\nShall be returned when the request has been accepted and completed.\nThe response body shall contain a representation of the attribute  modifications for the \"Individual NFV-MANO service interface\" resource, as defined in clause 5.6.2.13.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications that were performed on an  Individual NFV-MANO service interface\" resource. The attributes that can  be included consist of those requested to be modified explicitly in the  \"ManoServiceInterfaceModificationRequest\" data structure. If applicable,  additional attributes of the \"ManoServiceInterface\" data structure that  were modified implicitly shall also be provided. * NOTE:\tDue to the security sensitive information associated to the attribute, based on access control\n        policies, the API consumer might have read only, write only, read/write, or no access at all\n        to the attribute's value. In case the API consumer is not allowed to read the value of the security\n        sensitive attribute, the attribute shall be omitted when the information is to be provided\n        in a response message.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\" attribute in  \"ManoServiceInterface\", as defined in clause 5.6.2.11.\n","type":"string"},"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot  be executed currently, due to a conflict with the state of the  \"Individual NFV-MANO service interface\" resource.\nTypically, this is due to the fact that another operation is  ongoing.\nThe response body shall contain a ProblemDetails structure,  in which the \"detail\" attribute should convey more information  about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"412":{"description":"412 PRECONDITION FAILED\nShall be returned upon the following error: A precondition given  in an HTTP request header is not fulfilled.\nTypically, this is due to an ETag mismatch, indicating that the  resource was modified by another entity.\nThe response body should contain a ProblemDetails structure,  in which the \"detail\" attribute should convey more information  about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/mano_entity/mano_interfaces/{manoServiceInterfaceId}/change_state":{"parameters":[{"name":"manoServiceInterfaceId","in":"path","description":"Identifier of the MANO service interface.","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}],"post":{"description":"The POST method requests to change the state of the NFV-MANO service interface produced by the NFV-MANO functional entity. See clause 5.5.12.3.1.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"requestBody":{"description":"Parameters for the change state operation, as defined in  clause 5.6.2.8.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for changing the state of a managed entity. * NOTE 1:\tIn the present document version, a request shall only include an operational state change\n            (attribute \"operationalStateChange\") or an administrative state change request (attribute\n            \"administrativeStateChange\"), but not both.\n* NOTE 2:\tThe \"stopType\" shall only be provided when the \"operationalStateAction\" attribute is equal\n            to \"STOP\" or \"RESTART\". The \"gracefulStopTimeout\" shall be absent when the \"stopType\" attribute\n            is equal to \"FORCEFUL\", and may be provided otherwise.\n","type":"object","properties":{"operationalStateChange":{"description":"A change of operational state. Shall be present if the state change request refers to the operational state. See note 1. but not both.\n","type":"object","properties":{"operationalStateAction":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"stopType":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values  for the change state operation. It shall comply with the provisions:\n  - GRACEFUL\tTo stop the managed entity immediately after accepting the request.\n  - FORCEFUL\tTo stop the managed entity attempting to gracefully discharge the entity from service.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"gracefulStopTimeout":{"description":"The time internal (in seconds) to wait for the entity to be taken out  of service during graceful stop. See note 2.\n","type":"integer"}},"required":["operationalStateAction"]},"administrativeStateChange":{"description":"A change of administrative state. Shall be present if the state change request refers to the administrative state. See note 1. but not both.\n","type":"object","required":["administrativeStateAction"],"properties":{"administrativeStateAction":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]}}}}}}},"required":true},"responses":{"202":{"description":"202 ACCEPTED\nShall be returned when the request has been accepted for  processing.\nThe response body shall be empty.\nThe HTTP response shall include a “Location” HTTP header that  contains the URI of the newly-created \"Individual change state  operation occurrence\" resource corresponding to the operation.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual change state  operation occurence\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot be  executed currently, due to a conflict with the state of the resource.\nTypically, this is due to the fact that the resource is in an incompatible  state, or that another change state operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which the  \"detail\" attribute shall convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/subscriptions":{"post":{"description":"The POST method creates a new subscription. See clause 5.5.4.3.1.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"requestBody":{"description":"Details of the subscription to be created, as defined in  clause 5.6.2.5-1.\n","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to notifications  about NFV-MANO configuration and information management changes.\n","type":"object","properties":{"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"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.\n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n","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.\n","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.\n","type":"string"},"password":{"description":"Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","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.\n","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.\n","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.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}},"required":["callbackUri"]}}},"required":true},"responses":{"201":{"description":"201 CREATED\nShall be returned when the subscription has been created  successfully.\nThe response body shall contain a representation of the  created \"Individual subscription\" resource.\nThe HTTP response shall include a \"Location\" HTTP header  that points to the created \"Individual subscription\" resource.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual subscription\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about  NFV-MANO configuration and information management changes\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"required":["self"]}},"required":["id","callbackUri","_links"]}}}},"303":{"description":"303 SEE OTHER\nSShall be returned when a subscription with the same  callbackURI and the same filter already exists and the  policy of NFV-MANO functional entity is to not create  redundant subscriptions.\nThe HTTP response shall include a \"Location\" HTTP header  that contains the resource URI of the existing \"Individual  subscription\" resource.\nThe response body shall be empty.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual subscription\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 Unprocessable Entity\nShall be returned upon the following error: The content type of the payload body is supported and the payload body of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013, including rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the API producer has tested the Notification endpoint as described in clause 5.5.6.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"get":{"description":"The GET method queries the list of active subscriptions of the API consumer that invokes the method. It can be used, e.g. for resynchronization after error situations. See clause 5.5.4.3.2.\n","parameters":[{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of  ETSI GS NFV-SOL 013.\nThe NFV-MANO functional entity shall support receiving this parameter  as part of the URI query string. The API consumer may supply this  parameter.\nAll attribute names that appear in the CimSubscription and in data  types referenced from it shall be supported by the NFV-MANO functional  entity in the expression.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by  the NFV-MANO functional entity if the entity supports alternative 2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when the list of subscriptions has been queried  successfully.\nThe response body shall contain in an array the representations of  all active subscriptions of the functional block that invokes the  method, i.e., zero or more representations of NFV-MANO configuration  and information management subscriptions as defined in clause 5.6.2.6.\nIf the \"filter\" URI parameter was supplied in the request, the data in  the response body shall have been transformed according to the rules  specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the NFV-MANO functional entity supports alternative N°2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,  inclusion of the Link HTTP header in this response shall follow the  provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Link HTTP header in this response  shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","schema":{"type":"string","minimum":0,"maximum":1}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about  NFV-MANO configuration and information management changes\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"required":["self"]}},"required":["id","callbackUri","_links"]}}}}},"400":{"description":"400 BAD REQUEST\nShall be returned upon the following errors: \n  - Invalid attribute-based filtering expression.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Response too big.\n    If the NFV-MANO functional entity supports alternative N°1 (error) \n    according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, \n    this error response shall follow the provisions in clause 5.4.2.2 of \n    ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/subscriptions/{subscriptionId}":{"parameters":[{"name":"subscriptionId","in":"path","description":"Identifier of the subscription","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}],"get":{"description":"The GET method retrieves information about a subscription by reading an \"Individual subscription\" resource. See clause 5.5.5.3.2.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when information about an individual subscription  has been read successfully.\nThe response body shall contain a representation of the \"Individual  subscription\" resource.    headers:\nWWW-Authenticate:  description: >\n    Challenge if the corresponding HTTP request has not provided\n    authorization, or error details if the corresponding HTTP\n    request has provided an invalid authorization token.\n  schema:\n    type: string\nVersion:  description: >\n    Version of the API used in the response.\n  schema:\n    type: string\n","content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about  NFV-MANO configuration and information management changes\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"required":["self"]}},"required":["id","callbackUri","_links"]}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"delete":{"description":"The DELETE method terminates an individual subscription. See clause 5.5.5.3.5.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"204":{"description":"204 NO CONTENT\nShall be returned when the \"Individual subscription\" resource  has been deleted successfully.\nThe response body shall be empty.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/change_state_ops":{"get":{"description":"The API consumer can use the GET method to query status information  about multiple change state operation occurrences. See clause 5.5.8.3.2.\n","parameters":[{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of  ETSI GS NFV-SOL 013.\nThe NFV-MANO functional entity shall support receiving this parameter  as part of the URI query string. The API consumer may supply this  parameter.\nAll attribute names that appear in the ChangeStateOpOcc and in data  types referenced from it shall be supported by the NFV-MANO functional  entity in the expression.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"all_fields","description":"Include all complex attributes in the response. See clause  5.3 of ETSI GS NFV-SOL 013. The NFV-MANO functional entity  shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause  5.3 of ETSI GS NFV-SOL 013 for details. The NFV-MANO functional  entity should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause  5.3 of ETSI GS NFV-SOL 013 for details. The NFV-MANO functional  entity should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_default","description":"Indicates to exclude the following complex attributes from the  response. See clause 5.3 of ETSI GS NFV-SOL 013 for details.  The NFV-MANO functional entity shall support this parameter.\nThe following attributes shall be excluded from the ChangeStateOpOcc  structure in the response body if this parameter is provided, or none of  the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\"  are provided: - none\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by  the NFV-MANO functional entity if the entity supports alternative 2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when status information for zero or more  \"change state operation occurrences\" has been queried successfully.\nThe response body shall contain in an array the status information  about zero or more \"Individual change state operation occurrences\",  as defined in clause 5.6.2.9.\nIf the “filter\" URI parameter or one of the \"all_fields\", \"fields\"  (if supported), \"exclude_fields\" (if supported) or \"exclude_default\"  URI parameters was supplied in the request, the data in the response  body shall have been transformed according to the rules specified in  clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively.\nIf the NFV-MANO functional entity supports alternative N°2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,  inclusion of the Link HTTP header in this response shall follow the  provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Link HTTP header in this response  shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","schema":{"type":"string","minimum":0,"maximum":1}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a Change state operation occurrence.\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values for the change state operation. It shall comply with the provisions :\n  - PROCESSING\tThe change state operation is currently in execution.\n  - COMPLETED\tThe change state operation has been completed successfully.\n  - FAILED\tThe change state operation has failed.\n","type":"string","enum":["PROCESSING","COMPLETED","FAILED"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"managedObjectRef":{"description":"This type represents the identifier to reference a managed object of a  particular type.\n","type":"object","properties":{"type":{"description":"Indicates the type of managed object. Permitted values:  - MANO_ENTITY\n  - MANO_SERVICE\n  - MANO_SERVICE_IF\n  - CONSUMED_MANO_IF\n  - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n","type":"string","enum":["MANO_ENTITY","MANO_SERVICE","MANO_SERVICE_IF","CONSUMED_MANO_IF","MANO_ENTITY_COMPONENT"]},"objectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectId":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"required":["type","objectId"]},"changeOperationalStateRequest":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"changeAdministrativeStateRequest":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]},"operationParams":{"description":"Input parameters of the change state operation. This attribute shall be  formatted according to the request data type of the related change state  operation.\nThe following mapping between operationType and the data type of this  attribute shall apply:  - CHANGE_STATE: ChangeStateRequest\n  \nThis attribute shall be present if this data type is returned in a response  to reading an individual resource, and may be present according to the chosen  attribute selector parameter if this data type is returned in a response to  a query of a container resource.\n"}},"required":["id","operationState","stateEnteredTime","startTime","managedObjectRef"]}}}}},"400":{"description":"400 BAD REQUEST\nShall be returned upon the following errors: \n  - Invalid attribute-based filtering expression.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Invalid attribute selector.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Response too big.\n    If the NFV-MANO functional entity supports alternative N°1 (error) \n    according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, \n    this error response shall follow the provisions in clause 5.4.2.2 of \n    ETSI GS NFV-SOL 013.\n    headers:\nWWW-Authenticate:\n  description: >\n    Challenge if the corresponding HTTP request has not provided\n    authorization, or error details if the corresponding HTTP\n    request has provided an invalid authorization token.\n  schema:\n    type: string\nVersion:\n  description: >\n    Version of the API used in the response.\n  schema:\n    type: string\n","content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/change_state_ops/{changeStateOpOccId}":{"parameters":[{"name":"changeStateOpOccId","in":"path","description":"Identifier of the change state operation occurrence\n","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}],"get":{"description":"The API consumer can use the GET method to retrieve status  information about a change state operation occurrence by reading  an \"Individual change state operation occurrence\" resource. See clause 5.5.9.3.2.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when information about an \"Individual change  state operation occurrence\" resource has been read successfully.\nThe response body shall contain status information about a change  state operation occurrence, as defined in clause 5.6.2.9.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a Change state operation occurrence.\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values for the change state operation. It shall comply with the provisions :\n  - PROCESSING\tThe change state operation is currently in execution.\n  - COMPLETED\tThe change state operation has been completed successfully.\n  - FAILED\tThe change state operation has failed.\n","type":"string","enum":["PROCESSING","COMPLETED","FAILED"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"managedObjectRef":{"description":"This type represents the identifier to reference a managed object of a  particular type.\n","type":"object","properties":{"type":{"description":"Indicates the type of managed object. Permitted values:  - MANO_ENTITY\n  - MANO_SERVICE\n  - MANO_SERVICE_IF\n  - CONSUMED_MANO_IF\n  - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n","type":"string","enum":["MANO_ENTITY","MANO_SERVICE","MANO_SERVICE_IF","CONSUMED_MANO_IF","MANO_ENTITY_COMPONENT"]},"objectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectId":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"required":["type","objectId"]},"changeOperationalStateRequest":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"changeAdministrativeStateRequest":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]},"operationParams":{"description":"Input parameters of the change state operation. This attribute shall be  formatted according to the request data type of the related change state  operation.\nThe following mapping between operationType and the data type of this  attribute shall apply:  - CHANGE_STATE: ChangeStateRequest\n  \nThis attribute shall be present if this data type is returned in a response  to reading an individual resource, and may be present according to the chosen  attribute selector parameter if this data type is returned in a response to  a query of a container resource.\n"}},"required":["id","operationState","stateEnteredTime","startTime","managedObjectRef"]}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/peer_entities":{"post":{"description":"The POST method creates in the producer NFV-MANO functional entity a new peer entity resource which contains configuration and information with regards to the peer functional entity. See clause 5.5.13.3.1\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"requestBody":{"description":"The peer entity creation parameters, as defined in clause 5.6.2.14.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the creation of a new peer entity resource. * NOTE:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute\n        in the \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity,\n        and shall follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n","type":"object","required":["peerEntityId","name","type"],"properties":{"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\n","type":"string"},"consumedManoInterfaces":{"description":"Initial information of the interface consumed by the NFV-MANO functional entity from the peer functional entity.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"Current values of the state of the peer functional entity.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}}}},"required":true},"responses":{"201":{"description":"201 CREATED\nShall be returned when a new \"Individual peer entity\" resource  has been created successfully.\nThe response body shall contain a representation of the created  resource with regards to a peer entity, as defined in  clause 5.6.2.15.\nThe HTTP response shall include a “Location” HTTP header that  points to the created \"Individual peer entity\" resource.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual peer entity\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}},"content":{"application/json":{"schema":{"description":"This type represents an individual peer entity. * NOTE 1:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute in the\n            \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity, and shall\n            follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n* NOTE 2:\tETSI GS NFV-IFA 031 [1] defines an additional attribute named \"apiDiscoveryEndpoint\" in the\n            PeerManoEntity. The modelling of this attribute is not specified in the present document version.\n","type":"object","required":["id","peerEntityId","name","type","peerEntityState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"consumedManoInterfaces":{"description":"Information of the interface consumed by the NFV-MANO functional entity  from the peer functional entity.\nThis attribute can be modified with the PATCH method.\nThe keys of the map, each of which identifies information about a particular consumed NFV-MANO interface, are managed by the API consumer and referenced from other data structures via the \"consumedManoInterfaceIds\" attribute.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"State of the peer functional entity as provided by the API consumer when  creating the resource or when updating it with the PATCH method.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"get":{"description":"The GET method queries information and configuration in the producer NFV-MANO functional entity with regards to multiple peer entities. See clause 5.5.13.3.2.\n","parameters":[{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of  ETSI GS NFV-SOL 013.\nThe NFV-MANO functional entity shall support receiving this parameter  as part of the URI query string. The API consumer may supply this  parameter.\nAll attribute names that appear in the PeerEntity and in data  types referenced from it shall be supported by the NFV-MANO functional  entity in the expression.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"all_fields","description":"Include all complex attributes in the response. See clause  5.3 of ETSI GS NFV-SOL 013. The NFV-MANO functional entity  shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause  5.3 of ETSI GS NFV-SOL 013 for details. The NFV-MANO functional  entity should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause  5.3 of ETSI GS NFV-SOL 013 for details. The NFV-MANO functional  entity should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_default","description":"Indicates to exclude the following complex attributes from the  response. See clause 5.3 of ETSI GS NFV-SOL 013 for details.  The NFV-MANO functional entity shall support this parameter.\nThe following attributes shall be excluded from the PeerEntity  structure in the response body if this parameter is provided, or none of  the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\"  are provided: - none\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by  the NFV-MANO functional entity if the entity supports alternative 2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when information about zero or more peer  entities has been queried successfully.\nThe response body shall contain in an array the resource  representations of zero or more peer entities, as defined  in clause 5.6.2.15.\nIf the “filter\" URI parameter or one of the \"all_fields\", \"fields\"  (if supported), \"exclude_fields\" (if supported) or \"exclude_default\"  URI parameters was supplied in the request, the data in the response  body shall have been transformed according to the rules specified in  clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively.\nIf the NFV-MANO functional entity supports alternative N°2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,  inclusion of the Link HTTP header in this response shall follow the  provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Link HTTP header in this response  shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","schema":{"type":"string","minimum":0,"maximum":1}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents an individual peer entity. * NOTE 1:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute in the\n            \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity, and shall\n            follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n* NOTE 2:\tETSI GS NFV-IFA 031 [1] defines an additional attribute named \"apiDiscoveryEndpoint\" in the\n            PeerManoEntity. The modelling of this attribute is not specified in the present document version.\n","type":"object","required":["id","peerEntityId","name","type","peerEntityState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"consumedManoInterfaces":{"description":"Information of the interface consumed by the NFV-MANO functional entity  from the peer functional entity.\nThis attribute can be modified with the PATCH method.\nThe keys of the map, each of which identifies information about a particular consumed NFV-MANO interface, are managed by the API consumer and referenced from other data structures via the \"consumedManoInterfaceIds\" attribute.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"State of the peer functional entity as provided by the API consumer when  creating the resource or when updating it with the PATCH method.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}}}}}},"400":{"description":"400 BAD REQUEST\nShall be returned upon the following errors: \n  - Invalid attribute-based filtering expression.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Invalid attribute selector.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Response too big.\n    If the NFV-MANO functional entity supports alternative N°1 (error) \n    according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, \n    this error response shall follow the provisions in clause 5.4.2.2 of \n    ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/peer_entities/{peerEntityId}":{"parameters":[{"name":"peerEntityId","in":"path","description":"Identifier of the peer entity\n","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}],"get":{"description":"The GET method retrieves information and configuration hold in the producer NFV-MANO functional entity with regards to a peer entity by reading an individual peer entity resource. See clause 5.5.14.3.2.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"200 OK\nShall be returned when information about an individual peer  functional entity has been read successfully.\nThe response body shall contain a resource representation of  the peer functional entity, as defined in clause 5.6.2.15.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an individual peer entity. * NOTE 1:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute in the\n            \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity, and shall\n            follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n* NOTE 2:\tETSI GS NFV-IFA 031 [1] defines an additional attribute named \"apiDiscoveryEndpoint\" in the\n            PeerManoEntity. The modelling of this attribute is not specified in the present document version.\n","type":"object","required":["id","peerEntityId","name","type","peerEntityState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"consumedManoInterfaces":{"description":"Information of the interface consumed by the NFV-MANO functional entity  from the peer functional entity.\nThis attribute can be modified with the PATCH method.\nThe keys of the map, each of which identifies information about a particular consumed NFV-MANO interface, are managed by the API consumer and referenced from other data structures via the \"consumedManoInterfaceIds\" attribute.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"State of the peer functional entity as provided by the API consumer when  creating the resource or when updating it with the PATCH method.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"patch":{"description":"This method modifies configuration and information of the producer NFV-MANO functional entity with regards to a peer functional entity by updating the corresponding \"Individual peer entity\" resource. See clause 5.5.14.3.4.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"requestBody":{"description":"Parameters for the modification of configuration parameters of  the peer functional entity, as defined in clause 5.6.2.16\nThe Content-Type header shall be set to \"application/merge-patch+json\"  according to IETF RFC 7396.\n","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for configuration parameters of a peer entity. * NOTE:\tDue to the security sensitive information contained within the attribute (refer to \"securityInfo\"\n        within the \"ConsumedManoInterfaceInfo\"), based on access control policies, the API consumer might have\n        read only, write only, read/write, or no access at all to the attribute's value. In case the\n        API consumer is not allowed to modify the value of the security sensitive attribute, and the\n        modification request includes new attribute values, the whole modification request shall be rejected,\n        and proper error information returned.\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"PeerEntity\".\n","type":"string"},"description":{"description":"New value of the \"description\" attribute in \"PeerEntity\", or \"null\" to  remove the attribute.\n","type":"string"},"consumedManoInterfaces":{"description":"Modification of the \"consumedManoInterfaces\" attribute in the \"PeerEntity\", as defined below this table.\nIf present, these modifications shall be applied according to the rules of JSON Merge PATCH (see IETF RFC 7396). See note.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}}}}},"required":true},"responses":{"200":{"description":"200 OK\nShall be returned when the request has been accepted and completed.\nThe response body shall contain a representation of the attribute  modifications for the \"Individual peer entity\" resource, as defined  in clause 5.6.2.17.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications that were performed on an  \"Individual peer entity\" resource. The attributes that can be included  consist of those requested to be modified explicitly in the  \"PeerEntityConfigModificationRequest\" data structure. If applicable,  additional attributes of the \"PeerEntity\" data structure that were  modified implicitly shall also be provided. * NOTE:\tDue to the security sensitive information contained within the attribute (refer to \"securityInfo\"\n        within the \"ConsumedManoInterfaceInfo\"), based on access control policies, the API consumer might have\n        read only, write only, read/write, or no access at all to the attribute's value. In case the\n        API consumer is not allowed to read the value of the security sensitive attribute, the attribute shall\n        be omitted when the information is to be provided in a response message.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\" attribute  in \"PeerEntity\", as defined in clause 5.6.2.15.\n","type":"string"},"description":{"description":"If present, this attribute signals modifications of the \"description\"  attribute in \"PeerEntity\", as defined in clause 5.6.2.15.\n","type":"string"},"consumedManoInterfaces":{"description":"If present, this attribute signals modifications of the \"consumedManoInterfaces\" attribute in \"PeerEntity\", as defined in  clause 5.6.2.15. See note.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"409":{"description":"409 CONFLICT.\nShall be returned upon the following error: The operation cannot be  executed currently, due to a conflict with the state of the  \"Individual peer entity\" resource.\nTypically, this is due to the fact that another operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"412":{"description":"412 PRECONDITION FAILED\nShall be returned upon the following error: A precondition given in  an HTTP request header is not fulfilled.\nTypically, this is due to an ETag mismatch, indicating that the  resource was modified by another entity.\nThe response body should contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"delete":{"description":"This method deletes an individual peer entity resource. By deleting such a resource in the producer NFV-MANO functional entity representing a peer NFV-MANO entity, the configuration and information with regards to such peer entity is deleted. Consequently, the peering relationship between the producer NFV-MANO functional entity and the peer entity is terminated, i.e. the producer NFV-MANO functional entity does not have the necessary information to communicate/interact with the peer entity. See clause 5.5.14.3.5.\n","parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"responses":{"204":{"description":"204 NO CONTENT\nShall be returned when the \"Individual peer entity\" resource  has been deleted successfully.\nThe response body shall be empty.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}}},"401":{"description":"401 UNAUTHORIZED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"409":{"description":"409 CONFLICT.\nShall be returned upon the following error: The operation cannot be  executed currently, due to a conflict with the state of the  \"Individual peer entity\" resource.\nTypically, this is due to the fact that another operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"412":{"description":"412 PRECONDITION FAILED\nError: 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf 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 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}}},"components":{"schemas":{"ManoEntity":{"description":"This type represents an NFV-MANO functional entity. *  NOTE 1:\tIt shall be present when \"type\" attribute is \"NFVO\", and it shall be absent in any other case. *  NOTE 2:\tIt shall be present when \"type\" attribute is \"VNFM\", and it shall be absent in any other case. *  NOTE 3:\tIt shall be present when \"type\" attribute is \"VIM\", and it shall be absent in any other case. *  NOTE 4:\tThe information about the NFV-MANO services offered by a specific type of NFV-MANO functional\n            entity is specified by the manoServices attribute.\n*  NOTE 5:\tIt is optional for the API producer to support the \"manoEntityComponents\" attribute. *  NOTE 6:\tIt shall be present when \"type\" attribute is \"WIM\", and it shall be absent in any other case.\n","type":"object","required":["id","type","name","description","provider","softwareVersion","manoConfigurableParams","manoApplicationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"type":{"description":"The enumeration ManoEntityEnumType defines the permitted values to  represent NFV-MANO functional entities. It shall comply with  the provisions :\n  - NFVO\tThe NFV-MANO functional entity is an NFVO.\n  - VNFM\tThe NFV-MANO functional entity is a VNFM.\n  - VIM\t    The NFV-MANO functional entity is a VIM.\n  - WIM     The NFV-MANO functional entity is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM"]},"name":{"description":"Human-readable name of the NFV-MANO functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"description":{"description":"Human-readable description of the NFV-MANO functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"provider":{"description":"Information about the provider of the NFV-MANO functional entity.  It typically includes the name of the provider.\n","type":"string"},"softwareVersion":{"description":"A version.\n","type":"string"},"manoEntityComponents":{"description":"The deployed NFV-MANO functional entity components which realize the  NFV-MANO functional entity. See note 5.\n","type":"array","items":{"description":"This type represents information of a deployed component realizing part of an  NFV-MANO functional entity. It is optional for the API producer to support  this type.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"manoServiceIds":{"description":"References to the NFV-MANO services that depend on the NFV-MANO functional  entity component. The identifier of the ManoService is referred. A service  may depend on multiple components. Multiple services may depend on the same  component.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}}}}},"manoServices":{"description":"Information about the NFV-MANO services provided by the NFV-MANO  functional entity.\n","type":"array","items":{"description":"This type represents information about an NFV-MANO service provided by the  NFV-MANO functional entity. * NOTE:\tA cardinality greater than one supports having different interface versions or api Endpoints\n        to be used for accessing the same instance of an NFV-MANO service.\n","type":"object","properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO service.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"description":{"description":"Human-readable description of the NFV-MANO service.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"manoServiceInterfaceIds":{"description":"Reference to the NFV-MANO interfaces associated to the NFV-MANO service.  If cardinality is greater than one, the type of ManoServiceInterface  (see clause 5.6.3.3) shall be the same. The identifier of the  ManoServiceInterface is referred. See note\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"minItems":1},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"manoServiceInterfaces":{"description":"Link to the \"individual NFV-MANO service interface\" resources with  information about the associated interfaces to the NFV-MANO service.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"minItems":1}},"required":["manoServiceInterfaces"]}},"required":["id","name","description","manoServiceInterfaceIds","_links"]}},"manoConfigurableParams":{"description":"ManoConfigurableParams\n"},"manoApplicationState":{"description":"Information and current values of the NFV-MANO functional entity’s application state.\n","type":"object","required":["operationalState","administrativeState","usageState"],"properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]},"usageState":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]}}},"nfvoSpecificInfo":{"description":"This type represents information attributes specific to an NFVO entity,  and that can be relevant to more than one NFV-MANO service offered by an NFVO entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and version\n            of the specification. For instance, \"ETSI GS NFV-SOL 001 (V2.5.1)\".\n  NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined.\n","type":"object","properties":{"maxOnboardedNsdNum":{"description":"Maximum number of NSDs that can be on-boarded on the NFVO. See note 2.\n","type":"integer"},"maxOnboardedVnfPkgNum":{"description":"Maximum number of VNF Packages that can be on-boarded on the NFVO. See note 2.\n","type":"integer"},"supportedVnfdFormats":{"description":"Supported VNFD data formats.\n","type":"object","properties":{"vnfdFormat":{"description":"Name of the VNFD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["vnfdFormat","standardVersion"]},"supportedNsdFormats":{"description":"Supported NSD data formats.\n","type":"object","properties":{"nsdFormat":{"description":"Name of the NSD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["nsdFormat","standardVersion"]}},"required":["supportedVnfdFormats","supportedNsdFormats"]},"vnfmSpecificInfo":{"description":"This type represents information attributes specific to a VNFM entity,  and that can be relevant to more than one NFV-MANO service offered by a VNFM entity. * NOTE:\tThe information to be provided in this attribute shall relate to the specification and version\n        of the specification. For instance, \"ETSI GS NFV-SOL 001 (V2.5.1)\".\n","type":"object","properties":{"resoruceMgmtModeSupport":{"description":"The supported resource management modes of the VNFM.\nPermitted values:\n  - DIRECT: The VNFM supports direct mode only.\n  - INDIRECT: The VNFM supports indirect mode only.\n  - BOTH: The VNFM supports both direct and indirect mode.\n","type":"string","enum":["DIRECT","INDIRECT","BOTH"]},"managedVnfInstanceInfos":{"description":"The kinds of VNF instances that can be managed, e.g. to determine the  compatibility of a VNF with certain VNFM according to the vnfmInfo  attribute in the VNFD (see table 7.1.2.2-1 in ETSI GS NFV-IFA 011).\n","type":"array","items":{"type":"string"},"minItems":1},"supportedVnfdFormats":{"description":"Supported VNFD data formats.\n","type":"array","items":{"type":"object","properties":{"vnfdFormat":{"description":"Name of the VNFD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["vnfdFormat","standardVersion"]},"minItems":1}},"required":["resoruceMgmtModeSupport","managedVnfInstanceInfos","supportedVnfdFormats"]},"vimSpecificInfo":{"description":"This type represents information attributes specific to a VIM entity,  and that can be relevant to more than one NFV-MANO service offered by  a VIM entity.\n","type":"object"},"wimSpecificInfo":{"description":"This type represents information attributes specific to a WIM entity, and that can be relevant to more than one NFV MANO service offered by a WIM entity.\n","type":"object","required":["maxMscsNums","maxMsncNum","mscsLayerProtocolSupport"],"properties":{"maxMscsNums":{"description":"Maximum number of MSCS that the WIM can manage.\n","type":"object","required":["numMscs"],"properties":{"numMscs":{"description":"Maximum number of MSCS.\n","type":"integer"},"criteriaNumMscs":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"maxMsncNum":{"description":"Maximum number of MSNC that the WIM can manage\n","type":"object","required":["numMsnc"],"properties":{"numMsnc":{"description":"Maximum number of MSNC..\n","type":"integer"},"criteriaNumMsnc":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"mscsLayerProtocolSupport":{"description":"List of protocols of particular layers used to realize an MSCS that are supported by the WIM.\nPermitted values:  - EVPN_BGP_MPLS: L2 MSCS realized by BGP MPLS-based Ethernet VPN (EVPN) as specified in IETF RFC 7432.\n  - EVPN_VPWS: L2 MSCS realized by EVPN Virtual Private Wire Service (VPWS) as specified in IETF RFC 8214.\n  - VPLS_BGP: L2 MSCS realized by Virtual Private LAN Service (VPLS) using BGP as specified\n    in IETF RFC 4761 and IETF RFC.\n  - VPLS_LDP_L2TP: L2 MSCS realized by VPLS using Label Distribution Protocol (LDP) Layer 2\n    Tunnelling Protocol (L2TP) as specified in IETF RFC 4762 and IETF RFC 6074.\n  - VPWS_LDP_L2TP: L2 MSCS realized by VPWS using LDP L2TP as specified in IETF RFC 6074.\n  - BGP_IP_VPN: L3 MSCS realized by BGP/MPLS based IP VPN as specified in IETF RFC 4364.\n","type":"string","enum":["EVPN_BGP_MPLS","EVPN_VPWS","VPLS_BGP","VPLS_LDP_L2TP","VPWS_LDP_L2TP","BGP_IP_VPN"]}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","manoServiceInterfaces","peerEntities","changeState","changeStateOpOccs"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"manoServiceInterfaces":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"peerEntities":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeState":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeStateOpOccs":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"ManoConfigModificationRequest":{"description":"This type represents attribute modifications for configuration parameters  of an NFV-MANO functional entity. * NOTE:\tAt least one of these attributes shall be provided if requesting a modification\n        of the NFV-MANO service identified by \"id\".\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"ManoEntity\".\n","type":"string"},"description":{"description":"New value of the \"description\" attribute in \"ManoEntity\".\n","type":"string"},"clockSyncs":{"description":"Modifications of the \"clockSyncs\" attribute in the \"ManoEntityConfigurableParams\". If present, these modifications shall be applied according to the rules of JSON Merge PATCH (see IETF RFC 7396).\n","type":"object","additionalProperties":{"description":"This type represents parameters for connecting to an NTP server. * NOTE:\tEither ipAddress or hostname shall be set, but not both at the same time.\n","type":"object","properties":{"type":{"description":"Type of clock synchronization.\nPermitted values:\n  - NTP: For Network Time Protocol (NTP) based clock synchronization.\n  - OTHER: For other types of clock synchronization.\n","type":"string","enum":["NTP","OTHER"]},"ntpServerInfo":{"description":"Information for the NTP based clock synchronization. Shall be present if type = \"NTP\".\n","type":"object","properties":{"ipAddress":{"description":"An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n","type":"string","format":"IP"},"hostname":{"description":"Indicates the hostname of the NTP server. See note.\n","type":"string"}}},"otherClockSyncParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"required":["type"]}},"defaultLogCompileBySizeValue":{"description":"Unsigned integer\n","type":"number"},"defaultLogCompileByTimerValue":{"description":"Unsigned integer\n","type":"number"},"manoServiceModifications":{"description":"New content of certain entries in the \"manoServices\" attribute array  in the \"ManoEntity\", as defined below this table. The following provisions shall apply when modifying an attribute that is an array of structured \"manoServiceModifications\". Assumptions:\n  A)\t\"oldList\" is the array to be modified, \"newList\" is the array that contains the changes.\n  B)\t\"oldEntry\" is an entry in \"oldList\" and \"newEntry\" is an entry in \"newList\".\n  C)\tA \"newEntry\" has a \"corresponding entry\" if there exists an \"oldEntry\" that has the same\n        content of \"id\" attribute as the \"newEntry\".\n  D)\tIn any array of objects, the content of \"id\" is unique (i.e. there are no two entries\n        with the same content of \"id\").\nProvisions:\n  1)\tFor each \"newEntry\" in \"newList\" that has a corresponding \"oldEntry\" in \"oldList\", the values of\n        the sub-attributes of \"oldEntry\" shall be replaced by the value of the sub-attributes in the \"newEntry\".\n  2)\tIf the \"newEntry\" in \"newList\" has no corresponding \"oldEntry\" in \"oldList\" (i.e. the \"id\" is\n        not found), the modification operation will fail as a whole and an error message shall be raised.\n","type":"array","items":{"type":"object","required":["id"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"New value for the \"name\" attribute in the \"ManoService\". See note.\n","type":"string"},"description":{"description":"New value for the \"description\" attribute in the \"ManoService\". See note.\n","type":"string"}}}}}},"ManoConfigModifications":{"description":"This type represents attribute modifications that were performed on the  \"NFV-MANO entity\" resource of the producer NFV-MANO functional entity.  The attributes that can be included consist of those requested to be  modified explicitly in the \"ManoConfigModificationRequest\" data structure.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\"  attribute in \"ManoEntity\", as defined in clause 5.6.2.3\n","type":"string"},"description":{"description":"If present, this attribute signals modifications of the \"description\"  attribute in \"ManoEntity\", as defined in clause 5.6.2.3.\n","type":"string"},"clockSyncs":{"description":"If present, this attribute signals modifications of the \"clockSyncs\" attribute in \"ManoEntityConfigurableParams\", as defined in clause 5.6.2.3.\n","type":"object","additionalProperties":{"description":"This type represents parameters for connecting to an NTP server. * NOTE:\tEither ipAddress or hostname shall be set, but not both at the same time.\n","type":"object","properties":{"type":{"description":"Type of clock synchronization.\nPermitted values:\n  - NTP: For Network Time Protocol (NTP) based clock synchronization.\n  - OTHER: For other types of clock synchronization.\n","type":"string","enum":["NTP","OTHER"]},"ntpServerInfo":{"description":"Information for the NTP based clock synchronization. Shall be present if type = \"NTP\".\n","type":"object","properties":{"ipAddress":{"description":"An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n","type":"string","format":"IP"},"hostname":{"description":"Indicates the hostname of the NTP server. See note.\n","type":"string"}}},"otherClockSyncParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"required":["type"]}},"defaultLogCompileBySizeValue":{"description":"Unsigned integer\n","type":"number"},"defaultLogCompileByTimerValue":{"description":"Unsigned integer\n","type":"number"},"manoServiceModifications":{"description":"If present, this attribute signals modifications of the \"manoServices\"  attribute array in the \"ManoEntity\", as defined in clause 5.6.2.3.\n","type":"array","items":{"type":"object","properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"If present, this attribute signals modification of the \"name\"  attribute in the \"ManoService\".\n","type":"string"},"description":{"description":"If present, this attribute signals modification of the  \"description\" attribute in the \"ManoService\".\n","type":"string"}},"required":["id"]}}}},"CimSubscriptionRequest":{"description":"This type represents a subscription request related to notifications  about NFV-MANO configuration and information management changes.\n","type":"object","properties":{"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"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.\n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n","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.\n","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.\n","type":"string"},"password":{"description":"Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","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.\n","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.\n","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.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}},"required":["callbackUri"]},"CimSubscription":{"description":"This type represents a subscription related to notifications about  NFV-MANO configuration and information management changes\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"required":["self"]}},"required":["id","callbackUri","_links"]},"ChangeStateRequest":{"description":"This type represents request parameters for changing the state of a managed entity. * NOTE 1:\tIn the present document version, a request shall only include an operational state change\n            (attribute \"operationalStateChange\") or an administrative state change request (attribute\n            \"administrativeStateChange\"), but not both.\n* NOTE 2:\tThe \"stopType\" shall only be provided when the \"operationalStateAction\" attribute is equal\n            to \"STOP\" or \"RESTART\". The \"gracefulStopTimeout\" shall be absent when the \"stopType\" attribute\n            is equal to \"FORCEFUL\", and may be provided otherwise.\n","type":"object","properties":{"operationalStateChange":{"description":"A change of operational state. Shall be present if the state change request refers to the operational state. See note 1. but not both.\n","type":"object","properties":{"operationalStateAction":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"stopType":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values  for the change state operation. It shall comply with the provisions:\n  - GRACEFUL\tTo stop the managed entity immediately after accepting the request.\n  - FORCEFUL\tTo stop the managed entity attempting to gracefully discharge the entity from service.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"gracefulStopTimeout":{"description":"The time internal (in seconds) to wait for the entity to be taken out  of service during graceful stop. See note 2.\n","type":"integer"}},"required":["operationalStateAction"]},"administrativeStateChange":{"description":"A change of administrative state. Shall be present if the state change request refers to the administrative state. See note 1. but not both.\n","type":"object","required":["administrativeStateAction"],"properties":{"administrativeStateAction":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]}}}}},"ChangeStateOpOcc":{"description":"This type represents a Change state operation occurrence.\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values for the change state operation. It shall comply with the provisions :\n  - PROCESSING\tThe change state operation is currently in execution.\n  - COMPLETED\tThe change state operation has been completed successfully.\n  - FAILED\tThe change state operation has failed.\n","type":"string","enum":["PROCESSING","COMPLETED","FAILED"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"managedObjectRef":{"description":"This type represents the identifier to reference a managed object of a  particular type.\n","type":"object","properties":{"type":{"description":"Indicates the type of managed object. Permitted values:  - MANO_ENTITY\n  - MANO_SERVICE\n  - MANO_SERVICE_IF\n  - CONSUMED_MANO_IF\n  - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n","type":"string","enum":["MANO_ENTITY","MANO_SERVICE","MANO_SERVICE_IF","CONSUMED_MANO_IF","MANO_ENTITY_COMPONENT"]},"objectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectId":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"required":["type","objectId"]},"changeOperationalStateRequest":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"changeAdministrativeStateRequest":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]},"operationParams":{"description":"Input parameters of the change state operation. This attribute shall be  formatted according to the request data type of the related change state  operation.\nThe following mapping between operationType and the data type of this  attribute shall apply:  - CHANGE_STATE: ChangeStateRequest\n  \nThis attribute shall be present if this data type is returned in a response  to reading an individual resource, and may be present according to the chosen  attribute selector parameter if this data type is returned in a response to  a query of a container resource.\n"}},"required":["id","operationState","stateEnteredTime","startTime","managedObjectRef"]},"ManoServiceInterface":{"description":"This type represents an individual NFV-MANO service interface produced by  an NFV-MANO functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and\n            version of the specification. For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined. Overload is\n            handled by the error handling schemes defined by the applicable API specification.\n* NOTE 3:\tDue to the security sensitive information associated to the attribute, based on access\n            control policies, the API consumer might have read only, write only, read/write, or no access\n            at all to the attribute's value. In case the API consumer is not allowed to read the value of\n            the security sensitive attribute, the attribute shall be omitted when the information is to be\n            provided in a response message, and shall be provided otherwise. In case the API consumer is\n            not allowed to modify the value of the security sensitive attribute, and the modification request\n            includes new attribute values, the whole modification request shall be rejected, and proper\n            error information returned.\n","type":"object","required":["id","name","type","standardVersion","providerSpecificApiVersion","apiVersion","apiEndpoint","supportedOperations","interfaceState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO functional entity interface.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface produced by the NFV-MANO functional  entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"providerSpecificApiVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Exposed API endpoint of the interface.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1 of  ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"maxConcurrentIntOpNumber":{"description":"Maximum number of concurrent operation requests supported on this interface. See note 2.\n","type":"integer"},"supportedOperations":{"description":"Information about supported operations of this interface.\n","type":"array","items":{"type":"object","properties":{"operationName":{"description":"Name of the operation supported on the interface.\n","type":"string"},"maxConcurrentOpNumber":{"description":"Maximum number of concurrent requests supported by the interface operation. See note 2.\n","type":"integer"}},"required":["operationName"]},"minItems":1},"interfaceState":{"description":"State of the NFV-MANO service interface.\n","properties":{"operationalState":{"description":"The enumeration InterfaceOperationalStateEnumType defines values representing  the operational state of an NFV-MANO service interface type of managed entity.  The InterfaceOperationalStateEnumType shall comply with the provisions :\n   - STARTED\tThe managed entity is operational.\n   - STOPPED\tThe managed entity is not operational.\n   - STOPPING\tThe managed entity is in the transition to stop.\n   - STARTING\tThe managed entity is in the transition to start and become operational.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]},"usageState":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]}},"required":["operationalState","administrativeState","usageState"]},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"ManoServiceInterfaceModificationRequest":{"description":"This type represents attribute modifications for configuration parameters of  an NFV-MANO service interface of the producer NFV-MANO functional entity. * NOTE 1:\tChanging the name does not change the corresponding standardized API name in the resource URI\n            (refer to \"{apiName}\" defined in clause 4.1 of ETSI GS NFV-SOL 013).\n* NOTE 2:\tThe change of apiRoot or apiUri on an enabled and in use API may be service disruptive. Also,\n            that change invalidates any related URI that might have been cached at API consumers.\n* NOTE 3:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all\n            to the attribute's value. In case the API consumer is not allowed to modify the value of the\n            security sensitive attribute, and the modification request includes new attribute values,\n            the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"ManoServiceInterface\". See note 1.\n","type":"string"},"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"ManoServiceInterfaceModifications":{"description":"This type represents attribute modifications that were performed on an  Individual NFV-MANO service interface\" resource. The attributes that can  be included consist of those requested to be modified explicitly in the  \"ManoServiceInterfaceModificationRequest\" data structure. If applicable,  additional attributes of the \"ManoServiceInterface\" data structure that  were modified implicitly shall also be provided. * NOTE:\tDue to the security sensitive information associated to the attribute, based on access control\n        policies, the API consumer might have read only, write only, read/write, or no access at all\n        to the attribute's value. In case the API consumer is not allowed to read the value of the security\n        sensitive attribute, the attribute shall be omitted when the information is to be provided\n        in a response message.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\" attribute in  \"ManoServiceInterface\", as defined in clause 5.6.2.11.\n","type":"string"},"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"CreatePeerEntityRequest":{"description":"This type represents request parameters for the creation of a new peer entity resource. * NOTE:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute\n        in the \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity,\n        and shall follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n","type":"object","required":["peerEntityId","name","type"],"properties":{"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\n","type":"string"},"consumedManoInterfaces":{"description":"Initial information of the interface consumed by the NFV-MANO functional entity from the peer functional entity.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"Current values of the state of the peer functional entity.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}},"PeerEntity":{"description":"This type represents an individual peer entity. * NOTE 1:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute in the\n            \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity, and shall\n            follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n* NOTE 2:\tETSI GS NFV-IFA 031 [1] defines an additional attribute named \"apiDiscoveryEndpoint\" in the\n            PeerManoEntity. The modelling of this attribute is not specified in the present document version.\n","type":"object","required":["id","peerEntityId","name","type","peerEntityState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"consumedManoInterfaces":{"description":"Information of the interface consumed by the NFV-MANO functional entity  from the peer functional entity.\nThis attribute can be modified with the PATCH method.\nThe keys of the map, each of which identifies information about a particular consumed NFV-MANO interface, are managed by the API consumer and referenced from other data structures via the \"consumedManoInterfaceIds\" attribute.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"State of the peer functional entity as provided by the API consumer when  creating the resource or when updating it with the PATCH method.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}},"PeerEntityConfigModificationRequest":{"description":"This type represents attribute modifications for configuration parameters of a peer entity. * NOTE:\tDue to the security sensitive information contained within the attribute (refer to \"securityInfo\"\n        within the \"ConsumedManoInterfaceInfo\"), based on access control policies, the API consumer might have\n        read only, write only, read/write, or no access at all to the attribute's value. In case the\n        API consumer is not allowed to modify the value of the security sensitive attribute, and the\n        modification request includes new attribute values, the whole modification request shall be rejected,\n        and proper error information returned.\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"PeerEntity\".\n","type":"string"},"description":{"description":"New value of the \"description\" attribute in \"PeerEntity\", or \"null\" to  remove the attribute.\n","type":"string"},"consumedManoInterfaces":{"description":"Modification of the \"consumedManoInterfaces\" attribute in the \"PeerEntity\", as defined below this table.\nIf present, these modifications shall be applied according to the rules of JSON Merge PATCH (see IETF RFC 7396). See note.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}}},"PeerEntityConfigModifications":{"description":"This type represents attribute modifications that were performed on an  \"Individual peer entity\" resource. The attributes that can be included  consist of those requested to be modified explicitly in the  \"PeerEntityConfigModificationRequest\" data structure. If applicable,  additional attributes of the \"PeerEntity\" data structure that were  modified implicitly shall also be provided. * NOTE:\tDue to the security sensitive information contained within the attribute (refer to \"securityInfo\"\n        within the \"ConsumedManoInterfaceInfo\"), based on access control policies, the API consumer might have\n        read only, write only, read/write, or no access at all to the attribute's value. In case the\n        API consumer is not allowed to read the value of the security sensitive attribute, the attribute shall\n        be omitted when the information is to be provided in a response message.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\" attribute  in \"PeerEntity\", as defined in clause 5.6.2.15.\n","type":"string"},"description":{"description":"If present, this attribute signals modifications of the \"description\"  attribute in \"PeerEntity\", as defined in clause 5.6.2.15.\n","type":"string"},"consumedManoInterfaces":{"description":"If present, this attribute signals modifications of the \"consumedManoInterfaces\" attribute in \"PeerEntity\", as defined in  clause 5.6.2.15. See note.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}}},"ManoConfigurableParams":{"description":""},"ManoEntityComponent":{"description":"This type represents information of a deployed component realizing part of an  NFV-MANO functional entity. It is optional for the API producer to support  this type.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"manoServiceIds":{"description":"References to the NFV-MANO services that depend on the NFV-MANO functional  entity component. The identifier of the ManoService is referred. A service  may depend on multiple components. Multiple services may depend on the same  component.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}}}},"ManoService":{"description":"This type represents information about an NFV-MANO service provided by the  NFV-MANO functional entity. * NOTE:\tA cardinality greater than one supports having different interface versions or api Endpoints\n        to be used for accessing the same instance of an NFV-MANO service.\n","type":"object","properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO service.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"description":{"description":"Human-readable description of the NFV-MANO service.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"manoServiceInterfaceIds":{"description":"Reference to the NFV-MANO interfaces associated to the NFV-MANO service.  If cardinality is greater than one, the type of ManoServiceInterface  (see clause 5.6.3.3) shall be the same. The identifier of the  ManoServiceInterface is referred. See note\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"minItems":1},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"manoServiceInterfaces":{"description":"Link to the \"individual NFV-MANO service interface\" resources with  information about the associated interfaces to the NFV-MANO service.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"minItems":1}},"required":["manoServiceInterfaces"]}},"required":["id","name","description","manoServiceInterfaceIds","_links"]},"NfvoSpecificInfo":{"description":"This type represents information attributes specific to an NFVO entity,  and that can be relevant to more than one NFV-MANO service offered by an NFVO entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and version\n            of the specification. For instance, \"ETSI GS NFV-SOL 001 (V2.5.1)\".\n  NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined.\n","type":"object","properties":{"maxOnboardedNsdNum":{"description":"Maximum number of NSDs that can be on-boarded on the NFVO. See note 2.\n","type":"integer"},"maxOnboardedVnfPkgNum":{"description":"Maximum number of VNF Packages that can be on-boarded on the NFVO. See note 2.\n","type":"integer"},"supportedVnfdFormats":{"description":"Supported VNFD data formats.\n","type":"object","properties":{"vnfdFormat":{"description":"Name of the VNFD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["vnfdFormat","standardVersion"]},"supportedNsdFormats":{"description":"Supported NSD data formats.\n","type":"object","properties":{"nsdFormat":{"description":"Name of the NSD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["nsdFormat","standardVersion"]}},"required":["supportedVnfdFormats","supportedNsdFormats"]},"VnfmSpecificInfo":{"description":"This type represents information attributes specific to a VNFM entity,  and that can be relevant to more than one NFV-MANO service offered by a VNFM entity. * NOTE:\tThe information to be provided in this attribute shall relate to the specification and version\n        of the specification. For instance, \"ETSI GS NFV-SOL 001 (V2.5.1)\".\n","type":"object","properties":{"resoruceMgmtModeSupport":{"description":"The supported resource management modes of the VNFM.\nPermitted values:\n  - DIRECT: The VNFM supports direct mode only.\n  - INDIRECT: The VNFM supports indirect mode only.\n  - BOTH: The VNFM supports both direct and indirect mode.\n","type":"string","enum":["DIRECT","INDIRECT","BOTH"]},"managedVnfInstanceInfos":{"description":"The kinds of VNF instances that can be managed, e.g. to determine the  compatibility of a VNF with certain VNFM according to the vnfmInfo  attribute in the VNFD (see table 7.1.2.2-1 in ETSI GS NFV-IFA 011).\n","type":"array","items":{"type":"string"},"minItems":1},"supportedVnfdFormats":{"description":"Supported VNFD data formats.\n","type":"array","items":{"type":"object","properties":{"vnfdFormat":{"description":"Name of the VNFD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["vnfdFormat","standardVersion"]},"minItems":1}},"required":["resoruceMgmtModeSupport","managedVnfInstanceInfos","supportedVnfdFormats"]},"VimSpecificInfo":{"description":"This type represents information attributes specific to a VIM entity,  and that can be relevant to more than one NFV-MANO service offered by  a VIM entity.\n","type":"object"},"WimSpecificInfo":{"description":"This type represents information attributes specific to a WIM entity, and that can be relevant to more than one NFV MANO service offered by a WIM entity.\n","type":"object","required":["maxMscsNums","maxMsncNum","mscsLayerProtocolSupport"],"properties":{"maxMscsNums":{"description":"Maximum number of MSCS that the WIM can manage.\n","type":"object","required":["numMscs"],"properties":{"numMscs":{"description":"Maximum number of MSCS.\n","type":"integer"},"criteriaNumMscs":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"maxMsncNum":{"description":"Maximum number of MSNC that the WIM can manage\n","type":"object","required":["numMsnc"],"properties":{"numMsnc":{"description":"Maximum number of MSNC..\n","type":"integer"},"criteriaNumMsnc":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"mscsLayerProtocolSupport":{"description":"List of protocols of particular layers used to realize an MSCS that are supported by the WIM.\nPermitted values:  - EVPN_BGP_MPLS: L2 MSCS realized by BGP MPLS-based Ethernet VPN (EVPN) as specified in IETF RFC 7432.\n  - EVPN_VPWS: L2 MSCS realized by EVPN Virtual Private Wire Service (VPWS) as specified in IETF RFC 8214.\n  - VPLS_BGP: L2 MSCS realized by Virtual Private LAN Service (VPLS) using BGP as specified\n    in IETF RFC 4761 and IETF RFC.\n  - VPLS_LDP_L2TP: L2 MSCS realized by VPLS using Label Distribution Protocol (LDP) Layer 2\n    Tunnelling Protocol (L2TP) as specified in IETF RFC 4762 and IETF RFC 6074.\n  - VPWS_LDP_L2TP: L2 MSCS realized by VPWS using LDP L2TP as specified in IETF RFC 6074.\n  - BGP_IP_VPN: L3 MSCS realized by BGP/MPLS based IP VPN as specified in IETF RFC 4364.\n","type":"string","enum":["EVPN_BGP_MPLS","EVPN_VPWS","VPLS_BGP","VPLS_LDP_L2TP","VPWS_LDP_L2TP","BGP_IP_VPN"]}}},"ManoEntityConfigurableParams":{"description":"This type represents list of parameters that can be configured on the  NFV MANO functional entity.\n","type":"object","properties":{"clockSyncs":{"description":"Properties of the clock synchronization to be used by the NFV-MANO  functional entity.\nThe keys of the map, each of which identifies a particular ClockSyncInfo structure, are managed by the API consumer.\n","type":"object","additionalProperties":{"description":"This type represents parameters for connecting to an NTP server. * NOTE:\tEither ipAddress or hostname shall be set, but not both at the same time.\n","type":"object","properties":{"type":{"description":"Type of clock synchronization.\nPermitted values:\n  - NTP: For Network Time Protocol (NTP) based clock synchronization.\n  - OTHER: For other types of clock synchronization.\n","type":"string","enum":["NTP","OTHER"]},"ntpServerInfo":{"description":"Information for the NTP based clock synchronization. Shall be present if type = \"NTP\".\n","type":"object","properties":{"ipAddress":{"description":"An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n","type":"string","format":"IP"},"hostname":{"description":"Indicates the hostname of the NTP server. See note.\n","type":"string"}}},"otherClockSyncParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"required":["type"]},"minItems":1},"defaultLogCompileBySizeValue":{"description":"Unsigned integer\n","type":"number"},"defaultLogCompileByTimerValue":{"description":"Unsigned integer\n","type":"number"}},"required":["clockSyncs","defaultLogCompileBySizeValue","defaultLogCompileByTimerValue"]},"ConsumedManoInterfaceInfo":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]},"CimNotificationsFilter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"ClockSyncInfo":{"description":"This type represents parameters for connecting to an NTP server. * NOTE:\tEither ipAddress or hostname shall be set, but not both at the same time.\n","type":"object","properties":{"type":{"description":"Type of clock synchronization.\nPermitted values:\n  - NTP: For Network Time Protocol (NTP) based clock synchronization.\n  - OTHER: For other types of clock synchronization.\n","type":"string","enum":["NTP","OTHER"]},"ntpServerInfo":{"description":"Information for the NTP based clock synchronization. Shall be present if type = \"NTP\".\n","type":"object","properties":{"ipAddress":{"description":"An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n","type":"string","format":"IP"},"hostname":{"description":"Indicates the hostname of the NTP server. See note.\n","type":"string"}}},"otherClockSyncParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"required":["type"]},"ServerInterfaceSecurityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"ClientInterfaceSecurityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}},"ManoServiceInterfaceTypeShortName":{"description":"For the RESTful NFV-MANO APIs, valid values are all values for \"apiName\" as defined  in ETSI GS NFV-SOL 002, ETSI GS NFV-SOL 003, and ETSI GS NFV-SOL 005.\nFor the NFV-MANO service interfaces for which no API is specified by ETSI NFV, valid  values are defined in table 5.6.4.3-1.\nNOTE:\tThe table is expected to be updated, by removing the corresponding listed entries,  once the interfaces are specified as a RESTful NFV-MANO API. \n","type":"string"},"UsageStateEnumType":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]},"ChangeOperationalStateEnumType":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"ChangeAdministrativeStateEnumType":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]},"InterfaceOperationalStateEnumType":{"description":"The enumeration InterfaceOperationalStateEnumType defines values representing  the operational state of an NFV-MANO service interface type of managed entity.  The InterfaceOperationalStateEnumType shall comply with the provisions :\n   - STARTED\tThe managed entity is operational.\n   - STOPPED\tThe managed entity is not operational.\n   - STOPPING\tThe managed entity is in the transition to stop.\n   - STARTING\tThe managed entity is in the transition to start and become operational.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING"]},"StopEnumType":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values  for the change state operation. It shall comply with the provisions:\n  - GRACEFUL\tTo stop the managed entity immediately after accepting the request.\n  - FORCEFUL\tTo stop the managed entity attempting to gracefully discharge the entity from service.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"ManoEntityEnumType":{"description":"The enumeration ManoEntityEnumType defines the permitted values to  represent NFV-MANO functional entities. It shall comply with  the provisions :\n  - NFVO\tThe NFV-MANO functional entity is an NFVO.\n  - VNFM\tThe NFV-MANO functional entity is a VNFM.\n  - VIM\t    The NFV-MANO functional entity is a VIM.\n  - WIM     The NFV-MANO functional entity is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM"]},"PeerEntityEnumType":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]}},"parameters":{"filter.ManoServiceInterface":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of  ETSI GS NFV-SOL 013.\nThe NFV-MANO functional entity shall support receiving this parameter  as part of the URI query string. The API consumer may supply this  parameter.\nAll attribute names that appear in the ManoServiceInterface and in data  types referenced from it shall be supported by the NFV-MANO functional  entity in the expression.\n","in":"query","required":false,"schema":{"type":"string"}},"filter.CimSubscription":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of  ETSI GS NFV-SOL 013.\nThe NFV-MANO functional entity shall support receiving this parameter  as part of the URI query string. The API consumer may supply this  parameter.\nAll attribute names that appear in the CimSubscription and in data  types referenced from it shall be supported by the NFV-MANO functional  entity in the expression.\n","in":"query","required":false,"schema":{"type":"string"}},"filter.ChangeStateOpOcc":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of  ETSI GS NFV-SOL 013.\nThe NFV-MANO functional entity shall support receiving this parameter  as part of the URI query string. The API consumer may supply this  parameter.\nAll attribute names that appear in the ChangeStateOpOcc and in data  types referenced from it shall be supported by the NFV-MANO functional  entity in the expression.\n","in":"query","required":false,"schema":{"type":"string"}},"filter.PeerEntity":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of  ETSI GS NFV-SOL 013.\nThe NFV-MANO functional entity shall support receiving this parameter  as part of the URI query string. The API consumer may supply this  parameter.\nAll attribute names that appear in the PeerEntity and in data  types referenced from it shall be supported by the NFV-MANO functional  entity in the expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default.ManoServiceInterface":{"name":"exclude_default","description":"Indicates to exclude the following complex attributes from the  response. See clause 5.3 of ETSI GS NFV-SOL 013 for details.  The NFV-MANO functional entity shall support this parameter.\nThe following attributes shall be excluded from the ManoServiceInterface  structure in the response body if this parameter is provided, or none of  the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\"  are provided: - none\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default.CimSubscription":{"name":"exclude_default","description":"Indicates to exclude the following complex attributes from the  response. See clause 5.3 of ETSI GS NFV-SOL 013 for details.  The NFV-MANO functional entity shall support this parameter.\nThe following attributes shall be excluded from the CimSubscription  structure in the response body if this parameter is provided, or none of  the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\"  are provided: - none\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default.ChangeStateOpOcc":{"name":"exclude_default","description":"Indicates to exclude the following complex attributes from the  response. See clause 5.3 of ETSI GS NFV-SOL 013 for details.  The NFV-MANO functional entity shall support this parameter.\nThe following attributes shall be excluded from the ChangeStateOpOcc  structure in the response body if this parameter is provided, or none of  the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\"  are provided: - none\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default.PeerEntity":{"name":"exclude_default","description":"Indicates to exclude the following complex attributes from the  response. See clause 5.3 of ETSI GS NFV-SOL 013 for details.  The NFV-MANO functional entity shall support this parameter.\nThe following attributes shall be excluded from the PeerEntity  structure in the response body if this parameter is provided, or none of  the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\"  are provided: - none\n","in":"query","required":false,"schema":{"type":"string"}},"manoServiceInterfaceId":{"name":"manoServiceInterfaceId","in":"path","description":"Identifier of the MANO service interface.","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of the subscription","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"changeStateOpOccId":{"name":"changeStateOpOccId","in":"path","description":"Identifier of the change state operation occurrence\n","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"peerEntityId":{"name":"peerEntityId","in":"path","description":"Identifier of the peer entity\n","required":true,"schema":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}},"requestBodies":{"ModifyManoEntityRequest":{"description":"Parameters for the NFV-MANO configuration and information  modification, as defined in clause 5.6.2.3. The Content-Type header shall be set to \"application/merge-patch+json\"  according to IETF RFC 7396.\n","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for configuration parameters  of an NFV-MANO functional entity. * NOTE:\tAt least one of these attributes shall be provided if requesting a modification\n        of the NFV-MANO service identified by \"id\".\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"ManoEntity\".\n","type":"string"},"description":{"description":"New value of the \"description\" attribute in \"ManoEntity\".\n","type":"string"},"clockSyncs":{"description":"Modifications of the \"clockSyncs\" attribute in the \"ManoEntityConfigurableParams\". If present, these modifications shall be applied according to the rules of JSON Merge PATCH (see IETF RFC 7396).\n","type":"object","additionalProperties":{"description":"This type represents parameters for connecting to an NTP server. * NOTE:\tEither ipAddress or hostname shall be set, but not both at the same time.\n","type":"object","properties":{"type":{"description":"Type of clock synchronization.\nPermitted values:\n  - NTP: For Network Time Protocol (NTP) based clock synchronization.\n  - OTHER: For other types of clock synchronization.\n","type":"string","enum":["NTP","OTHER"]},"ntpServerInfo":{"description":"Information for the NTP based clock synchronization. Shall be present if type = \"NTP\".\n","type":"object","properties":{"ipAddress":{"description":"An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n","type":"string","format":"IP"},"hostname":{"description":"Indicates the hostname of the NTP server. See note.\n","type":"string"}}},"otherClockSyncParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"required":["type"]}},"defaultLogCompileBySizeValue":{"description":"Unsigned integer\n","type":"number"},"defaultLogCompileByTimerValue":{"description":"Unsigned integer\n","type":"number"},"manoServiceModifications":{"description":"New content of certain entries in the \"manoServices\" attribute array  in the \"ManoEntity\", as defined below this table. The following provisions shall apply when modifying an attribute that is an array of structured \"manoServiceModifications\". Assumptions:\n  A)\t\"oldList\" is the array to be modified, \"newList\" is the array that contains the changes.\n  B)\t\"oldEntry\" is an entry in \"oldList\" and \"newEntry\" is an entry in \"newList\".\n  C)\tA \"newEntry\" has a \"corresponding entry\" if there exists an \"oldEntry\" that has the same\n        content of \"id\" attribute as the \"newEntry\".\n  D)\tIn any array of objects, the content of \"id\" is unique (i.e. there are no two entries\n        with the same content of \"id\").\nProvisions:\n  1)\tFor each \"newEntry\" in \"newList\" that has a corresponding \"oldEntry\" in \"oldList\", the values of\n        the sub-attributes of \"oldEntry\" shall be replaced by the value of the sub-attributes in the \"newEntry\".\n  2)\tIf the \"newEntry\" in \"newList\" has no corresponding \"oldEntry\" in \"oldList\" (i.e. the \"id\" is\n        not found), the modification operation will fail as a whole and an error message shall be raised.\n","type":"array","items":{"type":"object","required":["id"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"New value for the \"name\" attribute in the \"ManoService\". See note.\n","type":"string"},"description":{"description":"New value for the \"description\" attribute in the \"ManoService\". See note.\n","type":"string"}}}}}}}},"required":true},"ChangeManoEntityStateRequest":{"description":"Parameters for the change state operation, as defined in clause 5.6.2.8.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for changing the state of a managed entity. * NOTE 1:\tIn the present document version, a request shall only include an operational state change\n            (attribute \"operationalStateChange\") or an administrative state change request (attribute\n            \"administrativeStateChange\"), but not both.\n* NOTE 2:\tThe \"stopType\" shall only be provided when the \"operationalStateAction\" attribute is equal\n            to \"STOP\" or \"RESTART\". The \"gracefulStopTimeout\" shall be absent when the \"stopType\" attribute\n            is equal to \"FORCEFUL\", and may be provided otherwise.\n","type":"object","properties":{"operationalStateChange":{"description":"A change of operational state. Shall be present if the state change request refers to the operational state. See note 1. but not both.\n","type":"object","properties":{"operationalStateAction":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"stopType":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values  for the change state operation. It shall comply with the provisions:\n  - GRACEFUL\tTo stop the managed entity immediately after accepting the request.\n  - FORCEFUL\tTo stop the managed entity attempting to gracefully discharge the entity from service.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"gracefulStopTimeout":{"description":"The time internal (in seconds) to wait for the entity to be taken out  of service during graceful stop. See note 2.\n","type":"integer"}},"required":["operationalStateAction"]},"administrativeStateChange":{"description":"A change of administrative state. Shall be present if the state change request refers to the administrative state. See note 1. but not both.\n","type":"object","required":["administrativeStateAction"],"properties":{"administrativeStateAction":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]}}}}}}},"required":true},"ModifyManoEnityInterfaceRequest":{"description":"Parameters for the modification of configuration parameters of  the NFV-MANO service interface, as defined in clause 5.6.2.12.\nThe Content-Type header shall be set to \"application/merge-patch+json\" according to IETF RFC 7396.\n","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for configuration parameters of  an NFV-MANO service interface of the producer NFV-MANO functional entity. * NOTE 1:\tChanging the name does not change the corresponding standardized API name in the resource URI\n            (refer to \"{apiName}\" defined in clause 4.1 of ETSI GS NFV-SOL 013).\n* NOTE 2:\tThe change of apiRoot or apiUri on an enabled and in use API may be service disruptive. Also,\n            that change invalidates any related URI that might have been cached at API consumers.\n* NOTE 3:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all\n            to the attribute's value. In case the API consumer is not allowed to modify the value of the\n            security sensitive attribute, and the modification request includes new attribute values,\n            the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"ManoServiceInterface\". See note 1.\n","type":"string"},"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"ChangeManoEntityInterfaceStateRequest":{"description":"Parameters for the change state operation, as defined in  clause 5.6.2.8.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for changing the state of a managed entity. * NOTE 1:\tIn the present document version, a request shall only include an operational state change\n            (attribute \"operationalStateChange\") or an administrative state change request (attribute\n            \"administrativeStateChange\"), but not both.\n* NOTE 2:\tThe \"stopType\" shall only be provided when the \"operationalStateAction\" attribute is equal\n            to \"STOP\" or \"RESTART\". The \"gracefulStopTimeout\" shall be absent when the \"stopType\" attribute\n            is equal to \"FORCEFUL\", and may be provided otherwise.\n","type":"object","properties":{"operationalStateChange":{"description":"A change of operational state. Shall be present if the state change request refers to the operational state. See note 1. but not both.\n","type":"object","properties":{"operationalStateAction":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"stopType":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values  for the change state operation. It shall comply with the provisions:\n  - GRACEFUL\tTo stop the managed entity immediately after accepting the request.\n  - FORCEFUL\tTo stop the managed entity attempting to gracefully discharge the entity from service.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"gracefulStopTimeout":{"description":"The time internal (in seconds) to wait for the entity to be taken out  of service during graceful stop. See note 2.\n","type":"integer"}},"required":["operationalStateAction"]},"administrativeStateChange":{"description":"A change of administrative state. Shall be present if the state change request refers to the administrative state. See note 1. but not both.\n","type":"object","required":["administrativeStateAction"],"properties":{"administrativeStateAction":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]}}}}}}},"required":true},"CimSubscriptionRequest":{"description":"Details of the subscription to be created, as defined in  clause 5.6.2.5-1.\n","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to notifications  about NFV-MANO configuration and information management changes.\n","type":"object","properties":{"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"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.\n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n","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.\n","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.\n","type":"string"},"password":{"description":"Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","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.\n","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.\n","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.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}},"required":["callbackUri"]}}},"required":true},"CreatePeerEntityRequest":{"description":"The peer entity creation parameters, as defined in clause 5.6.2.14.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the creation of a new peer entity resource. * NOTE:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute\n        in the \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity,\n        and shall follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n","type":"object","required":["peerEntityId","name","type"],"properties":{"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\n","type":"string"},"consumedManoInterfaces":{"description":"Initial information of the interface consumed by the NFV-MANO functional entity from the peer functional entity.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"Current values of the state of the peer functional entity.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}}}},"required":true},"ModifyPeerEntityRequest":{"description":"Parameters for the modification of configuration parameters of  the peer functional entity, as defined in clause 5.6.2.16\nThe Content-Type header shall be set to \"application/merge-patch+json\"  according to IETF RFC 7396.\n","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for configuration parameters of a peer entity. * NOTE:\tDue to the security sensitive information contained within the attribute (refer to \"securityInfo\"\n        within the \"ConsumedManoInterfaceInfo\"), based on access control policies, the API consumer might have\n        read only, write only, read/write, or no access at all to the attribute's value. In case the\n        API consumer is not allowed to modify the value of the security sensitive attribute, and the\n        modification request includes new attribute values, the whole modification request shall be rejected,\n        and proper error information returned.\n","type":"object","properties":{"name":{"description":"New value of the \"name\" attribute in \"PeerEntity\".\n","type":"string"},"description":{"description":"New value of the \"description\" attribute in \"PeerEntity\", or \"null\" to  remove the attribute.\n","type":"string"},"consumedManoInterfaces":{"description":"Modification of the \"consumedManoInterfaces\" attribute in the \"PeerEntity\", as defined below this table.\nIf present, these modifications shall be applied according to the rules of JSON Merge PATCH (see IETF RFC 7396). See note.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}}}}},"required":true}},"responses":{"ManoEntity.Get.200":{"description":"200 OK\nShall be returned when configuration and information about  the NFV-MANO functional entity has been read successfully. The response body shall contain a representation of the NFV-MANO functional entity, as defined in clause 5.6.2.2.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an NFV-MANO functional entity. *  NOTE 1:\tIt shall be present when \"type\" attribute is \"NFVO\", and it shall be absent in any other case. *  NOTE 2:\tIt shall be present when \"type\" attribute is \"VNFM\", and it shall be absent in any other case. *  NOTE 3:\tIt shall be present when \"type\" attribute is \"VIM\", and it shall be absent in any other case. *  NOTE 4:\tThe information about the NFV-MANO services offered by a specific type of NFV-MANO functional\n            entity is specified by the manoServices attribute.\n*  NOTE 5:\tIt is optional for the API producer to support the \"manoEntityComponents\" attribute. *  NOTE 6:\tIt shall be present when \"type\" attribute is \"WIM\", and it shall be absent in any other case.\n","type":"object","required":["id","type","name","description","provider","softwareVersion","manoConfigurableParams","manoApplicationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"type":{"description":"The enumeration ManoEntityEnumType defines the permitted values to  represent NFV-MANO functional entities. It shall comply with  the provisions :\n  - NFVO\tThe NFV-MANO functional entity is an NFVO.\n  - VNFM\tThe NFV-MANO functional entity is a VNFM.\n  - VIM\t    The NFV-MANO functional entity is a VIM.\n  - WIM     The NFV-MANO functional entity is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM"]},"name":{"description":"Human-readable name of the NFV-MANO functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"description":{"description":"Human-readable description of the NFV-MANO functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"provider":{"description":"Information about the provider of the NFV-MANO functional entity.  It typically includes the name of the provider.\n","type":"string"},"softwareVersion":{"description":"A version.\n","type":"string"},"manoEntityComponents":{"description":"The deployed NFV-MANO functional entity components which realize the  NFV-MANO functional entity. See note 5.\n","type":"array","items":{"description":"This type represents information of a deployed component realizing part of an  NFV-MANO functional entity. It is optional for the API producer to support  this type.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"manoServiceIds":{"description":"References to the NFV-MANO services that depend on the NFV-MANO functional  entity component. The identifier of the ManoService is referred. A service  may depend on multiple components. Multiple services may depend on the same  component.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}}}}},"manoServices":{"description":"Information about the NFV-MANO services provided by the NFV-MANO  functional entity.\n","type":"array","items":{"description":"This type represents information about an NFV-MANO service provided by the  NFV-MANO functional entity. * NOTE:\tA cardinality greater than one supports having different interface versions or api Endpoints\n        to be used for accessing the same instance of an NFV-MANO service.\n","type":"object","properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO service.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"description":{"description":"Human-readable description of the NFV-MANO service.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"manoServiceInterfaceIds":{"description":"Reference to the NFV-MANO interfaces associated to the NFV-MANO service.  If cardinality is greater than one, the type of ManoServiceInterface  (see clause 5.6.3.3) shall be the same. The identifier of the  ManoServiceInterface is referred. See note\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"minItems":1},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"manoServiceInterfaces":{"description":"Link to the \"individual NFV-MANO service interface\" resources with  information about the associated interfaces to the NFV-MANO service.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"minItems":1}},"required":["manoServiceInterfaces"]}},"required":["id","name","description","manoServiceInterfaceIds","_links"]}},"manoConfigurableParams":{"description":"ManoConfigurableParams\n"},"manoApplicationState":{"description":"Information and current values of the NFV-MANO functional entity’s application state.\n","type":"object","required":["operationalState","administrativeState","usageState"],"properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]},"usageState":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]}}},"nfvoSpecificInfo":{"description":"This type represents information attributes specific to an NFVO entity,  and that can be relevant to more than one NFV-MANO service offered by an NFVO entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and version\n            of the specification. For instance, \"ETSI GS NFV-SOL 001 (V2.5.1)\".\n  NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined.\n","type":"object","properties":{"maxOnboardedNsdNum":{"description":"Maximum number of NSDs that can be on-boarded on the NFVO. See note 2.\n","type":"integer"},"maxOnboardedVnfPkgNum":{"description":"Maximum number of VNF Packages that can be on-boarded on the NFVO. See note 2.\n","type":"integer"},"supportedVnfdFormats":{"description":"Supported VNFD data formats.\n","type":"object","properties":{"vnfdFormat":{"description":"Name of the VNFD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["vnfdFormat","standardVersion"]},"supportedNsdFormats":{"description":"Supported NSD data formats.\n","type":"object","properties":{"nsdFormat":{"description":"Name of the NSD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["nsdFormat","standardVersion"]}},"required":["supportedVnfdFormats","supportedNsdFormats"]},"vnfmSpecificInfo":{"description":"This type represents information attributes specific to a VNFM entity,  and that can be relevant to more than one NFV-MANO service offered by a VNFM entity. * NOTE:\tThe information to be provided in this attribute shall relate to the specification and version\n        of the specification. For instance, \"ETSI GS NFV-SOL 001 (V2.5.1)\".\n","type":"object","properties":{"resoruceMgmtModeSupport":{"description":"The supported resource management modes of the VNFM.\nPermitted values:\n  - DIRECT: The VNFM supports direct mode only.\n  - INDIRECT: The VNFM supports indirect mode only.\n  - BOTH: The VNFM supports both direct and indirect mode.\n","type":"string","enum":["DIRECT","INDIRECT","BOTH"]},"managedVnfInstanceInfos":{"description":"The kinds of VNF instances that can be managed, e.g. to determine the  compatibility of a VNF with certain VNFM according to the vnfmInfo  attribute in the VNFD (see table 7.1.2.2-1 in ETSI GS NFV-IFA 011).\n","type":"array","items":{"type":"string"},"minItems":1},"supportedVnfdFormats":{"description":"Supported VNFD data formats.\n","type":"array","items":{"type":"object","properties":{"vnfdFormat":{"description":"Name of the VNFD format.\nPermitted values:\n  - TOSCA: The VNFD follows TOSCA definition, according to ETSI \n  GS NFV-SOL 001 standard.\n  - YANG: The VNFD follows YANG definition according to ETSI \n  GS NFV-SOL 006 standard.\n","type":"string","enum":["TOSCA","YANG"]},"standardVersion":{"description":"A version.\n","type":"string"}},"required":["vnfdFormat","standardVersion"]},"minItems":1}},"required":["resoruceMgmtModeSupport","managedVnfInstanceInfos","supportedVnfdFormats"]},"vimSpecificInfo":{"description":"This type represents information attributes specific to a VIM entity,  and that can be relevant to more than one NFV-MANO service offered by  a VIM entity.\n","type":"object"},"wimSpecificInfo":{"description":"This type represents information attributes specific to a WIM entity, and that can be relevant to more than one NFV MANO service offered by a WIM entity.\n","type":"object","required":["maxMscsNums","maxMsncNum","mscsLayerProtocolSupport"],"properties":{"maxMscsNums":{"description":"Maximum number of MSCS that the WIM can manage.\n","type":"object","required":["numMscs"],"properties":{"numMscs":{"description":"Maximum number of MSCS.\n","type":"integer"},"criteriaNumMscs":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"maxMsncNum":{"description":"Maximum number of MSNC that the WIM can manage\n","type":"object","required":["numMsnc"],"properties":{"numMsnc":{"description":"Maximum number of MSNC..\n","type":"integer"},"criteriaNumMsnc":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"mscsLayerProtocolSupport":{"description":"List of protocols of particular layers used to realize an MSCS that are supported by the WIM.\nPermitted values:  - EVPN_BGP_MPLS: L2 MSCS realized by BGP MPLS-based Ethernet VPN (EVPN) as specified in IETF RFC 7432.\n  - EVPN_VPWS: L2 MSCS realized by EVPN Virtual Private Wire Service (VPWS) as specified in IETF RFC 8214.\n  - VPLS_BGP: L2 MSCS realized by Virtual Private LAN Service (VPLS) using BGP as specified\n    in IETF RFC 4761 and IETF RFC.\n  - VPLS_LDP_L2TP: L2 MSCS realized by VPLS using Label Distribution Protocol (LDP) Layer 2\n    Tunnelling Protocol (L2TP) as specified in IETF RFC 4762 and IETF RFC 6074.\n  - VPWS_LDP_L2TP: L2 MSCS realized by VPWS using LDP L2TP as specified in IETF RFC 6074.\n  - BGP_IP_VPN: L3 MSCS realized by BGP/MPLS based IP VPN as specified in IETF RFC 4364.\n","type":"string","enum":["EVPN_BGP_MPLS","EVPN_VPWS","VPLS_BGP","VPLS_LDP_L2TP","VPWS_LDP_L2TP","BGP_IP_VPN"]}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","manoServiceInterfaces","peerEntities","changeState","changeStateOpOccs"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"manoServiceInterfaces":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"peerEntities":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeState":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeStateOpOccs":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"ManoEntity.Patch.200":{"description":"200 OK\nShall be returned when the modification of configuration on the  NFV-MANO functional entity has been accepted and completed.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications that were performed on the  \"NFV-MANO entity\" resource of the producer NFV-MANO functional entity.  The attributes that can be included consist of those requested to be  modified explicitly in the \"ManoConfigModificationRequest\" data structure.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\"  attribute in \"ManoEntity\", as defined in clause 5.6.2.3\n","type":"string"},"description":{"description":"If present, this attribute signals modifications of the \"description\"  attribute in \"ManoEntity\", as defined in clause 5.6.2.3.\n","type":"string"},"clockSyncs":{"description":"If present, this attribute signals modifications of the \"clockSyncs\" attribute in \"ManoEntityConfigurableParams\", as defined in clause 5.6.2.3.\n","type":"object","additionalProperties":{"description":"This type represents parameters for connecting to an NTP server. * NOTE:\tEither ipAddress or hostname shall be set, but not both at the same time.\n","type":"object","properties":{"type":{"description":"Type of clock synchronization.\nPermitted values:\n  - NTP: For Network Time Protocol (NTP) based clock synchronization.\n  - OTHER: For other types of clock synchronization.\n","type":"string","enum":["NTP","OTHER"]},"ntpServerInfo":{"description":"Information for the NTP based clock synchronization. Shall be present if type = \"NTP\".\n","type":"object","properties":{"ipAddress":{"description":"An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n","type":"string","format":"IP"},"hostname":{"description":"Indicates the hostname of the NTP server. See note.\n","type":"string"}}},"otherClockSyncParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"required":["type"]}},"defaultLogCompileBySizeValue":{"description":"Unsigned integer\n","type":"number"},"defaultLogCompileByTimerValue":{"description":"Unsigned integer\n","type":"number"},"manoServiceModifications":{"description":"If present, this attribute signals modifications of the \"manoServices\"  attribute array in the \"ManoEntity\", as defined in clause 5.6.2.3.\n","type":"array","items":{"type":"object","properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"If present, this attribute signals modification of the \"name\"  attribute in the \"ManoService\".\n","type":"string"},"description":{"description":"If present, this attribute signals modification of the  \"description\" attribute in the \"ManoService\".\n","type":"string"}},"required":["id"]}}}}}}},"ManoEntity.Patch.409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot  be executed currently, due to a conflict with the state of the  \"NFV-MANO entity\" resource.\nTypically, this is due to the fact that another configuration and  information modification is ongoing.\nThe response body shall contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"ManoEntity.Patch.412":{"description":"412 PRECONDITION FAILED\nShall be returned upon the following error: A precondition given in  an HTTP request header is not fulfilled.\nTypically, this is due to an ETag mismatch, indicating that the resource  was modified by another entity.\nThe response body should contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"ChangeState.Post.202":{"description":"202 ACCEPTED\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that contains  the URI of the newly-created \"Individual change state operation occurrence\" resource corresponding to the operation.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual change state operation occurence\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}}},"ChangeState.Post.409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot be  executed currently, due to a conflict with the state of the resource.\nTypically, this is due to the fact that the resource is in an incompatible  state, or that another change state operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which the  \"detail\" attribute shall convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"ManoInterfaces.Get.200":{"description":"200 OK\nShall be returned when information about zero or more NFV-MANO  service interfaces has been queried successfully.\nThe response body shall contain in an array the representations  of zero or more NFV-MANO service interfaces, as defined in  clause 5.6.2.11.\nIf the “filter\" URI parameter or one of the \"all_fields\", \"fields\"  (if supported), \"exclude_fields\" (if supported) or \"exclude_default\"  URI parameters was supplied in the request, the data in the response  body shall have been transformed according to the rules specified in  clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively.\nIf the NFV-MANO functional entity supports alternative N°2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,  inclusion of the Link HTTP header in this response shall follow the  provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Link HTTP header in this response  shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","schema":{"type":"string","minimum":0,"maximum":1}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents an individual NFV-MANO service interface produced by  an NFV-MANO functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and\n            version of the specification. For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined. Overload is\n            handled by the error handling schemes defined by the applicable API specification.\n* NOTE 3:\tDue to the security sensitive information associated to the attribute, based on access\n            control policies, the API consumer might have read only, write only, read/write, or no access\n            at all to the attribute's value. In case the API consumer is not allowed to read the value of\n            the security sensitive attribute, the attribute shall be omitted when the information is to be\n            provided in a response message, and shall be provided otherwise. In case the API consumer is\n            not allowed to modify the value of the security sensitive attribute, and the modification request\n            includes new attribute values, the whole modification request shall be rejected, and proper\n            error information returned.\n","type":"object","required":["id","name","type","standardVersion","providerSpecificApiVersion","apiVersion","apiEndpoint","supportedOperations","interfaceState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO functional entity interface.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface produced by the NFV-MANO functional  entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"providerSpecificApiVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Exposed API endpoint of the interface.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1 of  ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"maxConcurrentIntOpNumber":{"description":"Maximum number of concurrent operation requests supported on this interface. See note 2.\n","type":"integer"},"supportedOperations":{"description":"Information about supported operations of this interface.\n","type":"array","items":{"type":"object","properties":{"operationName":{"description":"Name of the operation supported on the interface.\n","type":"string"},"maxConcurrentOpNumber":{"description":"Maximum number of concurrent requests supported by the interface operation. See note 2.\n","type":"integer"}},"required":["operationName"]},"minItems":1},"interfaceState":{"description":"State of the NFV-MANO service interface.\n","properties":{"operationalState":{"description":"The enumeration InterfaceOperationalStateEnumType defines values representing  the operational state of an NFV-MANO service interface type of managed entity.  The InterfaceOperationalStateEnumType shall comply with the provisions :\n   - STARTED\tThe managed entity is operational.\n   - STOPPED\tThe managed entity is not operational.\n   - STOPPING\tThe managed entity is in the transition to stop.\n   - STARTING\tThe managed entity is in the transition to start and become operational.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]},"usageState":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]}},"required":["operationalState","administrativeState","usageState"]},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}}},"ManoInterfaces.Get.400":{"description":"400 BAD REQUEST\nShall be returned upon the following errors: \n  - Invalid attribute-based filtering expression.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Invalid attribute selector.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Response too big.\n    If the NFV-MANO functional entity supports alternative N°1 (error) \n    according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, \n    this error response shall follow the provisions in clause 5.4.2.2 of \n    ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualManoInterface.Get.200":{"description":"200 OK\nShall be returned when information about an individual NFV-MANO  service interface has been read successfully.\nThe response body shall contain a representation of the NFV-MANO  service interface, as defined in clause 5.6.2.11.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an individual NFV-MANO service interface produced by  an NFV-MANO functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and\n            version of the specification. For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tIf this attribute is not present, the value of this parameter is undefined. Overload is\n            handled by the error handling schemes defined by the applicable API specification.\n* NOTE 3:\tDue to the security sensitive information associated to the attribute, based on access\n            control policies, the API consumer might have read only, write only, read/write, or no access\n            at all to the attribute's value. In case the API consumer is not allowed to read the value of\n            the security sensitive attribute, the attribute shall be omitted when the information is to be\n            provided in a response message, and shall be provided otherwise. In case the API consumer is\n            not allowed to modify the value of the security sensitive attribute, and the modification request\n            includes new attribute values, the whole modification request shall be rejected, and proper\n            error information returned.\n","type":"object","required":["id","name","type","standardVersion","providerSpecificApiVersion","apiVersion","apiEndpoint","supportedOperations","interfaceState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"},"name":{"description":"Human-readable name of the NFV-MANO functional entity interface.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface produced by the NFV-MANO functional  entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"providerSpecificApiVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Exposed API endpoint of the interface.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1 of  ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"maxConcurrentIntOpNumber":{"description":"Maximum number of concurrent operation requests supported on this interface. See note 2.\n","type":"integer"},"supportedOperations":{"description":"Information about supported operations of this interface.\n","type":"array","items":{"type":"object","properties":{"operationName":{"description":"Name of the operation supported on the interface.\n","type":"string"},"maxConcurrentOpNumber":{"description":"Maximum number of concurrent requests supported by the interface operation. See note 2.\n","type":"integer"}},"required":["operationName"]},"minItems":1},"interfaceState":{"description":"State of the NFV-MANO service interface.\n","properties":{"operationalState":{"description":"The enumeration InterfaceOperationalStateEnumType defines values representing  the operational state of an NFV-MANO service interface type of managed entity.  The InterfaceOperationalStateEnumType shall comply with the provisions :\n   - STARTED\tThe managed entity is operational.\n   - STOPPED\tThe managed entity is not operational.\n   - STOPPING\tThe managed entity is in the transition to stop.\n   - STARTING\tThe managed entity is in the transition to start and become operational.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]},"usageState":{"description":"The enumeration UsageStateEnumType defines values representing the usage  state of a managed entity.  The UsageStateEnumType shall comply with the provisions:\n  - IN_USE\tThe managed entity is currently being used.\n  - NOT_IN_USE\tThe managed entity is currently not being used.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]}},"required":["operationalState","administrativeState","usageState"]},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"IndividualManoInterface.Patch.200":{"description":"200 OK\nShall be returned when the request has been accepted and completed.\nThe response body shall contain a representation of the attribute  modifications for the \"Individual NFV-MANO service interface\" resource, as defined in clause 5.6.2.13.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications that were performed on an  Individual NFV-MANO service interface\" resource. The attributes that can  be included consist of those requested to be modified explicitly in the  \"ManoServiceInterfaceModificationRequest\" data structure. If applicable,  additional attributes of the \"ManoServiceInterface\" data structure that  were modified implicitly shall also be provided. * NOTE:\tDue to the security sensitive information associated to the attribute, based on access control\n        policies, the API consumer might have read only, write only, read/write, or no access at all\n        to the attribute's value. In case the API consumer is not allowed to read the value of the security\n        sensitive attribute, the attribute shall be omitted when the information is to be provided\n        in a response message.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\" attribute in  \"ManoServiceInterface\", as defined in clause 5.6.2.11.\n","type":"string"},"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"securityInfo":{"description":"This type represents security related information of an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API producer.\nThe support of authorization methods for the API producer is specified  in clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values:  - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246.\n  - OAUTH2: Using access token, as defined by the OAuth 2.0 specification \n  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","required":["providedConfiguration","tlsCipherSuites"],"properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of  the authorization server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API producer when performing the SSL or TLS negotiation with the authorization server. Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel.  Shall be present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  producer when performing the SSL or TLS negotiation with the API client.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string"},"minItems":1}},"required":["tlsTunnelCipherSuites"]}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"IndividualManoInterface.Patch.409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot  be executed currently, due to a conflict with the state of the  \"Individual NFV-MANO service interface\" resource.\nTypically, this is due to the fact that another operation is  ongoing.\nThe response body shall contain a ProblemDetails structure,  in which the \"detail\" attribute should convey more information  about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualManoInterface.Patch.412":{"description":"412 PRECONDITION FAILED\nShall be returned upon the following error: A precondition given  in an HTTP request header is not fulfilled.\nTypically, this is due to an ETag mismatch, indicating that the  resource was modified by another entity.\nThe response body should contain a ProblemDetails structure,  in which the \"detail\" attribute should convey more information  about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"ManoInterfaceChangeState.Post.202":{"description":"202 ACCEPTED\nShall be returned when the request has been accepted for  processing.\nThe response body shall be empty.\nThe HTTP response shall include a “Location” HTTP header that  contains the URI of the newly-created \"Individual change state  operation occurrence\" resource corresponding to the operation.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual change state  operation occurence\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}}},"ManoInterfaceChangeState.Post.409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot be  executed currently, due to a conflict with the state of the resource.\nTypically, this is due to the fact that the resource is in an incompatible  state, or that another change state operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which the  \"detail\" attribute shall convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"Subscriptions.Post.201":{"description":"201 CREATED\nShall be returned when the subscription has been created  successfully.\nThe response body shall contain a representation of the  created \"Individual subscription\" resource.\nThe HTTP response shall include a \"Location\" HTTP header  that points to the created \"Individual subscription\" resource.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual subscription\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about  NFV-MANO configuration and information management changes\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"required":["self"]}},"required":["id","callbackUri","_links"]}}}},"Subscriptions.Post.303":{"description":"303 SEE OTHER\nSShall be returned when a subscription with the same  callbackURI and the same filter already exists and the  policy of NFV-MANO functional entity is to not create  redundant subscriptions.\nThe HTTP response shall include a \"Location\" HTTP header  that contains the resource URI of the existing \"Individual  subscription\" resource.\nThe response body shall be empty.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual subscription\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}}},"Subscriptions.Post.422":{"description":"422 Unprocessable Entity\nShall be returned upon the following error: The content type of the payload body is supported and the payload body of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013, including rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the API producer has tested the Notification endpoint as described in clause 5.5.6.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"Subscriptions.Get.200":{"description":"200 OK\nShall be returned when the list of subscriptions has been queried  successfully.\nThe response body shall contain in an array the representations of  all active subscriptions of the functional block that invokes the  method, i.e., zero or more representations of NFV-MANO configuration  and information management subscriptions as defined in clause 5.6.2.6.\nIf the \"filter\" URI parameter was supplied in the request, the data in  the response body shall have been transformed according to the rules  specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the NFV-MANO functional entity supports alternative N°2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,  inclusion of the Link HTTP header in this response shall follow the  provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Link HTTP header in this response  shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","schema":{"type":"string","minimum":0,"maximum":1}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about  NFV-MANO configuration and information management changes\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"required":["self"]}},"required":["id","callbackUri","_links"]}}}}},"Subscriptions.Get.400":{"description":"400 BAD REQUEST\nShall be returned upon the following errors: \n  - Invalid attribute-based filtering expression.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Response too big.\n    If the NFV-MANO functional entity supports alternative N°1 (error) \n    according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, \n    this error response shall follow the provisions in clause 5.4.2.2 of \n    ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"Subscription.Get.200":{"description":"200 OK\nShall be returned when information about an individual subscription  has been read successfully.\nThe response body shall contain a representation of the \"Individual  subscription\" resource.    headers:\nWWW-Authenticate:  description: >\n    Challenge if the corresponding HTTP request has not provided\n    authorization, or error details if the corresponding HTTP\n    request has provided an invalid authorization token.\n  schema:\n    type: string\nVersion:  description: >\n    Version of the API used in the response.\n  schema:\n    type: string\n","content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about  NFV-MANO configuration and information management changes\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications  about NFV-MANO configuration and information management. * NOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names\n        of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"manoEntitySubscriptionFilter":{"description":"This type represents subscription filter criteria to match NFV-MANO functional  entities and their associated managed objects.\n","type":"object","properties":{"manoEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"manoServiceIds":{"description":"manoServiceIds\tIdentifierInManoEntity\t0..N\tIf present, match NFV-MANO  services with an instance identifier listed in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceNames":{"description":"If present, match NFV-MANO services with an NFV-MANO service name listed  in this attribute.\nThe attributes \"manoServiceIds\" and \"manoServiceNames\" are alternatives  to reference to NFV-MANO services in a filter. They should not be used  together in the same filter instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"manoServiceInterfaceIds":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance identifier listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"manoServiceInterfaceNames":{"description":"If present, match NFV-MANO functional entity produced interfaces with an  instance Name listed in this attribute.\nThe attributes \"manoServiceInterfaceIds\" and \"manoServiceInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity produced  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}},"consumedManoInterfaceIds":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance identifier listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"consumedManoInterfaceNames":{"description":"If present, match NFV-MANO functional entity consumed interfaces with an  instance Name listed in this attribute.\nThe attributes \"consumedManoInterfaceIds\" and \"consumedManoInterfaceNames\"  are alternatives to reference to NFV-MANO functional entity consumed  interfaces in a filter. They should not be used both in the same filter  instance, but one alternative should be chosen.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values:\n  - InformationChangedNotification\n  - ChangeStateNotification\n\nSee note.\n","type":"array","items":{"type":"string","enum":["InformationChangedNotification","ChangeStateNotification"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"required":["self"]}},"required":["id","callbackUri","_links"]}}}},"Subscription.Delete.204":{"description":"204 NO CONTENT\nShall be returned when the \"Individual subscription\" resource  has been deleted successfully.\nThe response body shall be empty.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}}},"ChangeStateOpOcc.Get.200":{"description":"200 OK\nShall be returned when status information for zero or more  \"change state operation occurrences\" has been queried successfully.\nThe response body shall contain in an array the status information  about zero or more \"Individual change state operation occurrences\",  as defined in clause 5.6.2.9.\nIf the “filter\" URI parameter or one of the \"all_fields\", \"fields\"  (if supported), \"exclude_fields\" (if supported) or \"exclude_default\"  URI parameters was supplied in the request, the data in the response  body shall have been transformed according to the rules specified in  clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively.\nIf the NFV-MANO functional entity supports alternative N°2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,  inclusion of the Link HTTP header in this response shall follow the  provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Link HTTP header in this response  shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","schema":{"type":"string","minimum":0,"maximum":1}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a Change state operation occurrence.\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values for the change state operation. It shall comply with the provisions :\n  - PROCESSING\tThe change state operation is currently in execution.\n  - COMPLETED\tThe change state operation has been completed successfully.\n  - FAILED\tThe change state operation has failed.\n","type":"string","enum":["PROCESSING","COMPLETED","FAILED"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"managedObjectRef":{"description":"This type represents the identifier to reference a managed object of a  particular type.\n","type":"object","properties":{"type":{"description":"Indicates the type of managed object. Permitted values:  - MANO_ENTITY\n  - MANO_SERVICE\n  - MANO_SERVICE_IF\n  - CONSUMED_MANO_IF\n  - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n","type":"string","enum":["MANO_ENTITY","MANO_SERVICE","MANO_SERVICE_IF","CONSUMED_MANO_IF","MANO_ENTITY_COMPONENT"]},"objectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectId":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"required":["type","objectId"]},"changeOperationalStateRequest":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"changeAdministrativeStateRequest":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]},"operationParams":{"description":"Input parameters of the change state operation. This attribute shall be  formatted according to the request data type of the related change state  operation.\nThe following mapping between operationType and the data type of this  attribute shall apply:  - CHANGE_STATE: ChangeStateRequest\n  \nThis attribute shall be present if this data type is returned in a response  to reading an individual resource, and may be present according to the chosen  attribute selector parameter if this data type is returned in a response to  a query of a container resource.\n"}},"required":["id","operationState","stateEnteredTime","startTime","managedObjectRef"]}}}}},"ChangeStateOpOcc.Get.400":{"description":"400 BAD REQUEST\nShall be returned upon the following errors: \n  - Invalid attribute-based filtering expression.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Invalid attribute selector.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Response too big.\n    If the NFV-MANO functional entity supports alternative N°1 (error) \n    according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, \n    this error response shall follow the provisions in clause 5.4.2.2 of \n    ETSI GS NFV-SOL 013.\n    headers:\nWWW-Authenticate:\n  description: >\n    Challenge if the corresponding HTTP request has not provided\n    authorization, or error details if the corresponding HTTP\n    request has provided an invalid authorization token.\n  schema:\n    type: string\nVersion:\n  description: >\n    Version of the API used in the response.\n  schema:\n    type: string\n","content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualChangeStateOpOcc.Get.200":{"description":"200 OK\nShall be returned when information about an \"Individual change  state operation occurrence\" resource has been read successfully.\nThe response body shall contain status information about a change  state operation occurrence, as defined in clause 5.6.2.9.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a Change state operation occurrence.\n","type":"object","properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"The enumeration ChangeStateOpOccStateEnumType defines permitted values for the change state operation. It shall comply with the provisions :\n  - PROCESSING\tThe change state operation is currently in execution.\n  - COMPLETED\tThe change state operation has been completed successfully.\n  - FAILED\tThe change state operation has failed.\n","type":"string","enum":["PROCESSING","COMPLETED","FAILED"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"managedObjectRef":{"description":"This type represents the identifier to reference a managed object of a  particular type.\n","type":"object","properties":{"type":{"description":"Indicates the type of managed object. Permitted values:  - MANO_ENTITY\n  - MANO_SERVICE\n  - MANO_SERVICE_IF\n  - CONSUMED_MANO_IF\n  - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n","type":"string","enum":["MANO_ENTITY","MANO_SERVICE","MANO_SERVICE_IF","CONSUMED_MANO_IF","MANO_ENTITY_COMPONENT"]},"objectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectId":{"description":"An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n","type":"string"}},"required":["type","objectId"]},"changeOperationalStateRequest":{"description":"The enumeration ChangeOperationalStateEnumType defines permitted values  for the change state operation.  The ChangeOperationalStateEnumType shall comply with the provisions:\n  - START\tTo start the managed entity.\n  - STOP\tTo stop the managed entity.\n  - RESTART\tTo stop and start again the managed entity.\n","type":"string","enum":["START","STOP","RESTART"]},"changeAdministrativeStateRequest":{"description":"The enumeration ChangeAdministrativeStateEnumType defines permitted values  for the change of administrative state operation.  The ChangeAdministrativeStateEnumType shall comply with the provisions:\n  - LOCK\tTo lock the managed entity.\n  - UNLOCK\tTo unlock the managed entity.\n","type":"string","enum":["LOCK","UNLOCK"]},"operationParams":{"description":"Input parameters of the change state operation. This attribute shall be  formatted according to the request data type of the related change state  operation.\nThe following mapping between operationType and the data type of this  attribute shall apply:  - CHANGE_STATE: ChangeStateRequest\n  \nThis attribute shall be present if this data type is returned in a response  to reading an individual resource, and may be present according to the chosen  attribute selector parameter if this data type is returned in a response to  a query of a container resource.\n"}},"required":["id","operationState","stateEnteredTime","startTime","managedObjectRef"]}}}},"PeerEntities.Post.201":{"description":"201 CREATED\nShall be returned when a new \"Individual peer entity\" resource  has been created successfully.\nThe response body shall contain a representation of the created  resource with regards to a peer entity, as defined in  clause 5.6.2.15.\nThe HTTP response shall include a “Location” HTTP header that  points to the created \"Individual peer entity\" resource.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Location":{"description":"The resource URI of the created \"Individual peer entity\" resource.\n","schema":{"type":"string","format":"url","minimum":1,"maximum":1}}},"content":{"application/json":{"schema":{"description":"This type represents an individual peer entity. * NOTE 1:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute in the\n            \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity, and shall\n            follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n* NOTE 2:\tETSI GS NFV-IFA 031 [1] defines an additional attribute named \"apiDiscoveryEndpoint\" in the\n            PeerManoEntity. The modelling of this attribute is not specified in the present document version.\n","type":"object","required":["id","peerEntityId","name","type","peerEntityState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"consumedManoInterfaces":{"description":"Information of the interface consumed by the NFV-MANO functional entity  from the peer functional entity.\nThis attribute can be modified with the PATCH method.\nThe keys of the map, each of which identifies information about a particular consumed NFV-MANO interface, are managed by the API consumer and referenced from other data structures via the \"consumedManoInterfaceIds\" attribute.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"State of the peer functional entity as provided by the API consumer when  creating the resource or when updating it with the PATCH method.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}}}}},"PeerEntities.Get.200":{"description":"200 OK\nShall be returned when information about zero or more peer  entities has been queried successfully.\nThe response body shall contain in an array the resource  representations of zero or more peer entities, as defined  in clause 5.6.2.15.\nIf the “filter\" URI parameter or one of the \"all_fields\", \"fields\"  (if supported), \"exclude_fields\" (if supported) or \"exclude_default\"  URI parameters was supplied in the request, the data in the response  body shall have been transformed according to the rules specified in  clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively.\nIf the NFV-MANO functional entity supports alternative N°2 (paging)  according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,  inclusion of the Link HTTP header in this response shall follow the  provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Link HTTP header in this response  shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","schema":{"type":"string","minimum":0,"maximum":1}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents an individual peer entity. * NOTE 1:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute in the\n            \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity, and shall\n            follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n* NOTE 2:\tETSI GS NFV-IFA 031 [1] defines an additional attribute named \"apiDiscoveryEndpoint\" in the\n            PeerManoEntity. The modelling of this attribute is not specified in the present document version.\n","type":"object","required":["id","peerEntityId","name","type","peerEntityState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"consumedManoInterfaces":{"description":"Information of the interface consumed by the NFV-MANO functional entity  from the peer functional entity.\nThis attribute can be modified with the PATCH method.\nThe keys of the map, each of which identifies information about a particular consumed NFV-MANO interface, are managed by the API consumer and referenced from other data structures via the \"consumedManoInterfaceIds\" attribute.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"State of the peer functional entity as provided by the API consumer when  creating the resource or when updating it with the PATCH method.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}}}}}},"PeerEntities.Get.400":{"description":"400 BAD REQUEST\nShall be returned upon the following errors: \n  - Invalid attribute-based filtering expression.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Invalid attribute selector.\n    The response body shall contain a ProblemDetails structure, in which \n    the \"detail\" attribute should convey more information about the error.\n  - Response too big.\n    If the NFV-MANO functional entity supports alternative N°1 (error) \n    according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, \n    this error response shall follow the provisions in clause 5.4.2.2 of \n    ETSI GS NFV-SOL 013.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualPeerEntity.Get.200":{"description":"200 OK\nShall be returned when information about an individual peer  functional entity has been read successfully.\nThe response body shall contain a resource representation of  the peer functional entity, as defined in clause 5.6.2.15.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an individual peer entity. * NOTE 1:\tThe value of the \"peerEntityId\" attribute is the same as the value of the \"id\" attribute in the\n            \"ManoEntity\" of the corresponding NFV-MANO functional entity that acts as peer entity, and shall\n            follow the uniqueness requirements set out in clause 5.6.2.2 for the \"id\" attribute.\n* NOTE 2:\tETSI GS NFV-IFA 031 [1] defines an additional attribute named \"apiDiscoveryEndpoint\" in the\n            PeerManoEntity. The modelling of this attribute is not specified in the present document version.\n","type":"object","required":["id","peerEntityId","name","type","peerEntityState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"peerEntityId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human-readable name of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"type":{"description":"The enumeration PeerEntityEnumType defines the permitted values  to represent peer functional entities. it shall complains with  the provisions :  - NFVO\tThe peer functional entity is an NFVO. - VNFM\tThe peer functional entity is a VNFM. - VIM\t  The peer functional entity is a VIM. - WIM\t  The peer functional entity is a WIM. - EM\t  The peer functional entity is an EM. - OSS\t  The peer functional entity is an OSS/BSS. - WIM     The peer functional is a WIM.\n","type":"string","enum":["NFVO","VNFM","VIM","WIM","EM","OSS","WIM"]},"description":{"description":"Human-readable description of the peer functional entity.\nThis attribute can be modified with the PATCH method.\n","type":"string"},"consumedManoInterfaces":{"description":"Information of the interface consumed by the NFV-MANO functional entity  from the peer functional entity.\nThis attribute can be modified with the PATCH method.\nThe keys of the map, each of which identifies information about a particular consumed NFV-MANO interface, are managed by the API consumer and referenced from other data structures via the \"consumedManoInterfaceIds\" attribute.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"peerEntityState":{"description":"State of the peer functional entity as provided by the API consumer when  creating the resource or when updating it with the PATCH method.\n","type":"object","properties":{"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}},"required":["operationalState","administrativeState"]}}}}}},"IndividualPeerEntity.Patch.200":{"description":"200 OK\nShall be returned when the request has been accepted and completed.\nThe response body shall contain a representation of the attribute  modifications for the \"Individual peer entity\" resource, as defined  in clause 5.6.2.17.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications that were performed on an  \"Individual peer entity\" resource. The attributes that can be included  consist of those requested to be modified explicitly in the  \"PeerEntityConfigModificationRequest\" data structure. If applicable,  additional attributes of the \"PeerEntity\" data structure that were  modified implicitly shall also be provided. * NOTE:\tDue to the security sensitive information contained within the attribute (refer to \"securityInfo\"\n        within the \"ConsumedManoInterfaceInfo\"), based on access control policies, the API consumer might have\n        read only, write only, read/write, or no access at all to the attribute's value. In case the\n        API consumer is not allowed to read the value of the security sensitive attribute, the attribute shall\n        be omitted when the information is to be provided in a response message.\n","type":"object","properties":{"name":{"description":"If present, this attribute signals modifications of the \"name\" attribute  in \"PeerEntity\", as defined in clause 5.6.2.15.\n","type":"string"},"description":{"description":"If present, this attribute signals modifications of the \"description\"  attribute in \"PeerEntity\", as defined in clause 5.6.2.15.\n","type":"string"},"consumedManoInterfaces":{"description":"If present, this attribute signals modifications of the \"consumedManoInterfaces\" attribute in \"PeerEntity\", as defined in  clause 5.6.2.15. See note.\n","type":"object","additionalProperties":{"description":"This type represents an interface consumed by the producer NFV MANO  functional entity from another peer functional entity. * NOTE 1:\tThe information to be provided in this attribute shall relate to the specification and its version.\n            For instance, \"ETSI GS NFV-SOL 003 (V2.4.1)\".\n* NOTE 2:\tDue to the security sensitive information associated to the attribute, based on access control\n            policies, the API consumer might have read only, write only, read/write, or no access at all to\n            the attribute's value. In case the API consumer is not allowed to read the value of the security\n            sensitive attribute, the attribute shall be omitted when the information is to be provided in a\n            response message, and shall be provided otherwise. In case the API consumer is not allowed to\n            modify the value of the security sensitive attribute, and the modification request includes new\n            attribute values, the whole modification request shall be rejected, and proper error information returned.\n","type":"object","properties":{"name":{"description":"Human-readable name of the NFV-MANO interface.\n","type":"string"},"type":{"description":"Type of the NFV-MANO service interface consumed by the NFV-MANO  functional entity. Valid values are defined in clause 5.6.4.3.\n","type":"string"},"standardVersion":{"description":"A version.\n","type":"string"},"apiVersion":{"description":"A version.\n","type":"string"},"apiEndpoint":{"description":"Consumable API endpoint of the interface. It provides the information relevant about the protocol, host and port,  and path where the interface API can be accessed.\n","type":"object","properties":{"apiRoot":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"apiName":{"description":"Indicates the interface name in an abbreviated form. Shall be present  for ETSI NFV specified RESTful NFV-MANO APIs. The {apiName} of each  interface is defined in the standard the interface is compliant to  (see also clause 4.1 of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiMajorVersion":{"description":"Indicates the current major version of the API. Shall be present for  ETSI NFV specified RESTful NFV-MANO APIs. The major version is defined  in the standard the interface is compliant to (see also clause 4.1  of ETSI GS NFV-SOL 013). May be present otherwise.\n","type":"string"},"apiUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"required":["apiUri"]},"securityInfo":{"description":"This type represents security related information for accessing an NFV-MANO  service interface produced by an NFV-MANO functional entity. * NOTE:\tProvided configuration of the OAuth 2.0 authorization server information and configuration\n        shall be supported, and dynamic configuration may be supported.\n","type":"object","required":["authType","oauthServerInfo"],"properties":{"authType":{"description":"Type of API request authorization to be used by the API consumer accessing  the API.\nThe support of authorization methods for the API consumer is specified in  clause 8.3.6 of ETSI GS NFV-SOL 013.\nPermitted values: - TLS_TUNNEL: Using TLS tunnel, as defined by TLS 1.2 in IETF RFC 5246. - OAUTH2: Using access token, as defined by the OAuth 2.0 specification  in IETF RFC 6749.\n","type":"array","items":{"type":"string","enum":["TLS_TUNNEL","OAUTH2"]},"minItems":1},"oauthServerInfo":{"description":"OAuth 2.0 authorization server information and configuration.\n","type":"object","properties":{"dynamicDiscovery":{"description":"Configuration data used when performing dynamic discovery of the authorization  server identifier. See note.\n","type":"object","required":["webFingerHost"],"properties":{"webFingerHost":{"description":"Server where the WebFinger service is hosted. When used, the request to  the WebFinger resource shall conform as specified in clause 5.1.3 of  ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"providedConfiguration":{"description":"Configuration data used to setup the authorization server identifier. See note.\n","type":"object","required":["authServerId"],"properties":{"authServerId":{"description":"Authorization server identifier as defined in ETSI GS NFV-SEC 022.\n","type":"string","format":"uri"}}},"tlsCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API consumer when  performing the SSL or TLS negotiation with the authorization server. Valid values  of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}},"tlsTunnelInfo":{"description":"Information and configuration related to the use of TLS tunnel. Shall be  present if authType contains \"TLS_TUNNEL\".\n","type":"object","properties":{"tlsTunnelCipherSuites":{"description":"List of cipher suites that shall be declared as supported by the API  consumer when performing the SSL or TLS negotiation with the API producer.  Valid values of cipher suites are defined in IETF RFC 8447.\n","type":"array","items":{"type":"string","minItems":1}}}}}}},"required":["id","name","type","standardVersion","apiVersion","apiEndpoint"]}},"operationalState":{"description":"The enumeration OperationalStateEnumType defines values representing the operational state of an NFV-MANO functional application type of managed entity. The OperationalStateEnumType shall comply with the provisions:\n  - STARTED\tThe managed entity is operational.\n  - STOPPED\tThe managed entity is not operational.\n  - STOPPING\tThe managed entity is in the transition to stop.\n  - STARTING\tThe managed entity is in the transition to start and become operational.\n  - RESTARTING\tThe managed entity is in the transition to stop and start again.\n","type":"string","enum":["STARTED","STOPPED","STOPPING","STARTING","RESTARTING"]},"administrativeState":{"description":"The enumeration AdministrativeStateEnumType defines values representing the administrative state of a managed entity. The AdministrativeStateEnumType shall comply with the provisions:\n  - LOCKED\tThe managed entity is administratively prohibited to be used.\n  - UNLOCKED\tThe managed entity is administratively allowed to be used.\n  - LOCKING\tThe managed entity is in the transition to be locked.\n","type":"string","enum":["LOCKED","UNLOCKED","LOCKING"]}}}}}},"IndividualPeerEntity.Patch.409":{"description":"409 CONFLICT.\nShall be returned upon the following error: The operation cannot be  executed currently, due to a conflict with the state of the  \"Individual peer entity\" resource.\nTypically, this is due to the fact that another operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualPeerEntity.Patch.412":{"description":"412 PRECONDITION FAILED\nShall be returned upon the following error: A precondition given in  an HTTP request header is not fulfilled.\nTypically, this is due to an ETag mismatch, indicating that the  resource was modified by another entity.\nThe response body should contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualPeerEntity.Delete.204":{"description":"204 NO CONTENT\nShall be returned when the \"Individual peer entity\" resource  has been deleted successfully.\nThe response body shall be empty.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}}},"IndividualPeerEntity.Delete.409":{"description":"409 CONFLICT.\nShall be returned upon the following error: The operation cannot be  executed currently, due to a conflict with the state of the  \"Individual peer entity\" resource.\nTypically, this is due to the fact that another operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualPeerEntity.Delete.412":{"description":"412 PRECONDITION FAILED\nShall be returned upon the following error: A precondition given in  an HTTP request header is not fulfilled.\nTypically, this is due to an ETag mismatch, indicating that the  resource was modified by another entity.\nThe response body should contain a ProblemDetails structure, in which  the \"detail\" attribute should convey more information about the error.\n","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.\n","schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string"}}},"content":{"application/json":{"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].\n","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\".\n","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).\n","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.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}}