"description":"VNF Configuration interface of ETSI NFV SOL002\n\nIMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to. In case of discrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=---\n",
"summary":"Read VNF/VNFC configuration from VNF.",
"description":"The client can use this method to read configuration information about a VNF instance and/or its VNFC instances.\n",
"responses":{
"200":{
"description":"OK\nConfiguration information about a VNF instance was read successfully. The response body shall contain a representation of the configuration resource.\n",
"schema":{
"$ref":"#/definitions/VnfConfiguration"
}
},
"400":{
"description":"Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\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.\n ---\n\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.\n",
"headers":{
"Content-Type":{
"description":"The MIME type of the body of the response.",
"type":"string",
"maximum":1,
"minimum":1
},
"WWW-Authenticate":{
"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
"type":"string",
"maximum":1,
"minimum":0
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"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.",
"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",
"type":"string",
"maximum":1,
"minimum":0
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"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.",
"type":"string",
"maximum":1,
"minimum":1
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"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.\n",
"headers":{
"Content-Type":{
"description":"The MIME type of the body of the response.",
"type":"string",
"maximum":1,
"minimum":1
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"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 in that case.\n",
"headers":{
"Content-Type":{
"description":"The MIME type of the body of the response.",
"type":"string",
"maximum":1,
"minimum":1
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"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 in that case.\n",
"headers":{
"Content-Type":{
"description":"The MIME type of the body of the response.",
"type":"string",
"maximum":1,
"minimum":1
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"Conflict\nAnother request is in progress that prohibits the fulfilment of the current request, or the current resource state is inconsistent with the request.\n",
"headers":{
"Content-Type":{
"description":"The MIME type of the body of the response.",
"type":"string",
"maximum":1,
"minimum":1
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"Requested Range Not Satisfiable\nThis code is returned if the requested byte range in the Range HTTP header is not present in the requested resource.\n",
"headers":{
"Content-Type":{
"description":"The MIME type of the body of the response.",
"type":"string",
"maximum":1,
"minimum":1
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"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. NOTE 2: This 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.",
"type":"string",
"maximum":1,
"minimum":1
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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":"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 withthis 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.",
"type":"string",
"maximum":1,
"minimum":1
}
},
"schema":{
"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\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",
