diff --git a/GS_NFV-SOL_026.md b/GS_NFV-SOL_026.md
index 9e6dec07d3363166163fb9dcd88aca340af6e5ec..ca3ac2d024a5a4f217bf7768e8a8db55836ebd14 100644
--- a/GS_NFV-SOL_026.md
+++ b/GS_NFV-SOL_026.md
@@ -454,7 +454,8 @@ This clause describes a sequence for modifying an individual Computer System res
**Figure 6.4.4-1: Flow of Computer System modification**
-The modification of an individual Computer System resource, as illustrated in Figure 6.4.41, consists of the following steps.
+The modification of an individual Computer System resource, as illustrated in Figure 6.4.4-1, consists of the following steps.
+The modification of an individual Computer System resource, as illustrated in Figure 6.4.4-1, consists of the following steps.
**Precondition:** The individual Computer System resource has been previously created.
@@ -883,7 +884,8 @@ This clause describes a sequence for modifying an individual topology object.
**Figure 8.4.4-1: Flow of topology object modification**
-The modification of a topology object, as illustrated in Figure 8.4.41, consists of the following steps.
+The modification of a topology object, as illustrated in Figure 8.4.4-1, consists of the following steps.
+The modification of a topology object, as illustrated in Figure 8.4.4-1, consists of the following steps.
**Precondition:** The individual topology object has been previously created.
@@ -1174,7 +1176,8 @@ Figures 9.3-1, 9.3-2, 9.3-3 and 9.3-4 show resource structures of the Redfish&re
Table 9.3-1 lists the API resources, and the applicable HTTP methods for each resource endpoint.
-The HTTP methods marked as "M" (mandatory) in the "Cat" column of table 9.3-1 shall be supported by the PIM. The HTTP methods marked as "O" (optional) in the "Cat" column may be optionally supported by the PIM.
+The HTTP methods marked as "M" (mandatory) in the "Cat" column of table 9.3-1 shall be supported by the PIM. The HTTP methods marked as "O" (optional) in the "Cat" column may be optionally supported by the PIM. The HTTP methods marked as "CM" (conditional mandatory) shall be supported by the PIM depending on the corresponding condition.
+The HTTP methods marked as "M" (mandatory) in the "Cat" column of table 9.3-1 shall be supported by the PIM. The HTTP methods marked as "O" (optional) in the "Cat" column may be optionally supported by the PIM. The HTTP methods marked as "CM" (conditional mandatory) shall be supported by the PIM depending on the corresponding condition.
**Table 9.3-1: API Resources and HTTP methods of physical resource performance management service interface**
@@ -1226,13 +1229,184 @@ The HTTP methods marked as "M" (mandatory) in the "Cat" column of table 9.3-1 sh
| | |DELETE |M |Delete an "Individual Subscription" resource. |
+-------------------------+---------------------------------+-----------------+----------+----------------------------------------------------------+
|Notification endpoint |{NotificationTargetURI} |POST |M |Send a notification related to |
-| | | | |a subscribed event (see note). |
+| | | | |a subscribed event (see note 1). |
+| | | | |Can also be used to send a performance |
+| | | | |report asynchronously (see note 2). |
+| | | | |a subscribed event (see note 1). |
+| | | | |Can also be used to send a performance |
+| | | | |report asynchronously (see note 2). |
++-------------------------+---------------------------------+-----------------+----------+----------------------------------------------------------+
+|Individual Task Monitor |/redfish/v1/TaskService\ |GET |CM |Enable API consumer to monitor the |
+| |/TaskMonitors/{TaskMonitorId} | | |progress of an asynchronous operation |
+| |(see note 3) | | |as well as receive the result of the requested |
+| | | | |operation once the corresponding task has been completed. |
+| | | | |This resource endpoint shall be supported |
+| | | | |if the API producer supports asynchronous operations. |
+-------------------------+---------------------------------+-----------------+----------+----------------------------------------------------------+
-|NOTE: Notification endpoint resource and the corresponding NotficiationTargetURI |
+|NOTE 1: Notification endpoint resource and the corresponding NotficiationTargetURI |
|is used by the API producer to send notifications to the API consumer. |
|This resource is not produced by the API producer. |
+|NOTE 2: See clause 9.4.8 for the flow related to the API consumers receiving |
+|performance reports asynchronously as notifications. . |
+|NOTE 3: The URI of the task monitor is provided in the Location header |
+|of the HTTP response to the API consumer when the API producer returns a "202 Accepted" response. |
+|NOTE 2: See clause 9.4.8 for the flow related to the API consumers receiving |
+|performance reports asynchronously as notifications. . |
+|NOTE 3: The URI of the task monitor is provided in the Location header |
+|of the HTTP response to the API consumer when the API producer returns a "202 Accepted" response. |
+---------------------------------------------------------------------------------------------------------------------------------------------------+
+## 9.4 Sequence diagrams (informative)
+
+### 9.4.1 Introduction
+
+The sequence diagrams provided in the subsequent sub-clauses are generalized to indicate management of a generic performance management (PM) related object, which refers to either PmJob or Threshold specified in clause 5 of the present document. These diagrams and their description contain placeholders such as <PM object collection URI>, <PM object URI> and <PM object>, which correspond to the appropriate resource URIs and PM-related objects specified in clauses 9.3 and 5.4 respectively.
+
+Sequence diagrams related to retrieval of performance reports do not contain generic placeholders. Specific resource URIs and object names are used in those sequence diagrams.
+
+Flows related to task monitoring, subscription management and notifications are described in Annex A of the present document.
+
+### 9.4.2 Creation of a PM object
+
+This clause describes a sequence for creating an individual resource corresponding to a PM object.
+
+
+
+**Figure 9.4.2-1: Flow of PM object creation**
+
+The creation of a PM object, as illustrated in Figure 9.4.2-1, consists of the following steps.
+
+**Precondition:** None.
+
+1. The API consumer sends a POST request to the <PM object collection URI> including a valid <PM object> representation in the message content body.
+1. If the PIM supports asynchronous operations and creation of the PM object resource requires some time to process, the PIM returns a "202 Accepted" response. The response also contains the URI of the associated Task Monitor in the Location header. The response body can optionally contain representation of the corresponding Task resource created by the PIM for this asynchronous operation.
+1. The PIM creates an individual PM object.
+1. The PIM returns a "201 Created" response to the API consumer and includes in the message content body a representation of the created PM object. The response also contains the URI of the newly created PM object in the Location header.
+
+**Postcondition:** Upon successful completion of the synchronous operation or of the corresponding task in case of asynchronous operation, the individual PM object has been created.
+
+**Error handling:** In case of failure, appropriate error information is provided in the response.
+
+### 9.4.3 Querying information about PM objects
+
+This clause describes the sequences for querying information about multiple and individual PM objects.
+
+
+
+**Figure 9.4.3-1: Flow of querying information about PM objects**
+
+The querying of information about one or more PM objects, as illustrated in Figure 9.4.3-1, consists of the following steps.
+
+**Precondition:** One or more individual PM objects have previously been created.
+
+1. If the API consumer intends to get information about multiple PM objects, it sends a GET request to the <PM object collection URI>.
+1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of a <PM object collection>, containing information about all the individual PM objects that have been created.
+1. If the API consumer intends to get information about an individual PM object, it sends a GET request to the <PM object URI>.
+1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of the individual PM object.
+
+**Postcondition:** None.
+
+**Error handling:** In case of failure, appropriate error information is provided in the response.
+
+### 9.4.4 Modifying a PM object
+
+This clause describes a sequence for modifying an individual PM object.
+
+
+
+**Figure 9.4.4-1: Flow of PM object modification**
+
+The modification of a PM object, as illustrated in Figure 9.4.4-1, consists of the following steps.
+
+**Precondition:** The individual PM object has been previously created.
+
+1. The API consumer sends a PATCH request to the <PM object URI>, including data structure in the message content body representing the modifiable properties to be modified in the individual PM object.
+1. If the PIM supports asynchronous operations and modification of the PM object requires some time to process, the PIM returns a "202 Accepted" response. The response also contains the URI of the associated Task Monitor in the Location header. The response body can optionally contain representation of the corresponding Task resource created by the PIM for this asynchronous operation.
+1. The PIM modifies the individual PM object.
+1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of the modified PM object. Alternatively, the PIM can also return a "204 No Content" response to the API consumer indicating successful operation.
+
+**Postcondition:** Upon successful completion of the synchronous operation or of the corresponding task in case of asynchronous operation, the individual PM object has been modified.
+
+**Error handling:** In case of failure, appropriate error information is provided in the response.
+
+### 9.4.5 Replacing a PM object
+
+This clause describes a sequence for replacing an individual PM object.
+
+
+
+**Figure 9.4.5-1: Flow of PM object replacement**
+
+The replacement of an individual PM object, as illustrated in Figure 9.4.5-1, consists of the following steps.
+
+**Precondition:** The individual PM object has been previously created.
+
+1. The API consumer sends a PUT request to the <PM object URI> including a valid representation of the individual PM object to be replaced in the message content body.
+1. If the PIM supports asynchronous operations and replacement of the PM object requires some time to process, the PIM returns a "202 Accepted" response. The response also contains the URI of the associated Task Monitor in the Location header. The response body can optionally contain representation of the corresponding Task resource created by the PIM for this asynchronous operation.
+1. The PIM replaces the individual PM object.
+1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of the replaced PM object. Alternatively, the PIM can also return a "204 No Content" response to the API consumer indicating successful operation.
+
+**Postcondition:** Upon successful completion of the synchronous operation or of the corresponding task in case of asynchronous operation, the individual PM object has been replaced.
+
+**Error handling:** In case of failure, appropriate error information is provided in the response.
+
+### 9.4.6 Deleting a PM object
+
+This clause describes a sequence for deleting an individual PM object.
+
+
+
+**Figure 9.4.6-1: Flow of PM object deletion**
+
+The deletion of an individual PM object, as illustrated in Figure 9.4.6-1, consists of the following steps.
+
+**Precondition:** The individual PM object has been previously created.
+
+1. The API consumer sends a DELETE request to the <PM object URI>.
+1. If the PIM supports asynchronous operations and deletion of the PM object requires some time to process, the PIM returns a "202 Accepted" response. The response also contains the URI of the associated Task Monitor in the Location header. The response body can optionally contain representation of the corresponding Task resource created by the PIM for this asynchronous operation.
+1. The PIM deletes the individual PM object.
+1. The PIM returns a "204 No Content " response to the API consumer indicating that the PM object has been successfully deleted. Alternatively, the PIM can also return a "200 OK" response to the API consumer including a representation of the deleted PM object in the message content body.
+
+**Postcondition:** Upon successful completion of the synchronous operation or of the corresponding task in case of asynchronous operation, the individual PM object has been deleted.
+
+**Error handling:** In case of failure, appropriate error information is provided in the response.
+
+### 9.4.7 Retrieving performance reports
+
+This clause describes the sequence for querying information about multiple and individual performance reports.
+
+
+
+**Figure 9.4.7-1: Flow of querying information about performance reports**
+
+The querying of information about one or more performance reports, as illustrated in Figure 9.4.7-1, consists of the following steps.
+
+**Precondition:** One or more individual performance reports have previously been generated by the PIM.
+
+1. If the API consumer intends to get information about multiple performance reports, it sends a GET request to the performance reports URI.
+1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of a collection of performance reports, containing information about all the individual performance reports that have been generated.
+1. If the API consumer intends to get information about an individual performance report, it sends a GET request to the URI representing individual performance report.
+1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of the individual performance report.
+
+**Postcondition:** None.
+
+**Error handling:** In case of failure, appropriate error information is provided in the response.
+
+### 9.4.8 Receiving performance reports asynchronously
+
+This clause describes the sequence for receiving performance reports asynchrnously as notifications.
+
+
+
+**Figure 9.4.8-1: Flow of receiving performance reports as notifications**
+
+The procedure consists of the following steps as illustrated in figure 9.4.8-1.
+
+**Precondition:** The API consumer has previously created a subscription containing a PmJob to receive performance reports asynchronously.
+
+1. When generating a performance report according to the configured PmJob (*MetricReportDefinition*) as part of the created subscription, an event of type *MetricReport* gets triggered. As a result of this, the PIM generates a notification that includes the performance report and sends it in the body of a POST request to the notification target URI which the API consumer had registered as part of the subscription request.
+
+<<<<<<< HEAD
## 9.5 Resources
### 9.5.1 Introduction
@@ -1459,6 +1633,11 @@ The URI query parameters, request and response bodies, and response codes of the
## 9.6 Data model
The request and response data structures of the physical resource performance management service interface are defined in the Redfish® data model specification [\[3\]](#_ref_3).
+=======
+**Postcondition:** None.
+
+**Error handling:** None.
+>>>>>>> 8d782de (add postcondition and error handling fields in notification related flows)
# 10 Physical resource fault management service interface
@@ -1523,6 +1702,10 @@ The procedure consists of the following steps as illustrated in figure A.3-1.
1. If an event occurs that matches the eventing criteria which are part of the subscription, the PIM generates a notification that includes information about the event and sends it in the body of a POST request to the notification target URI which the API consumer had registered as part of the subscription request.
+**Postcondition:** None.
+
+**Error handling:** None.
+
Editor's Note: To further check in Redfish interface specs and potentially with DMTF Redfish experts about the standard response (if any) from API consumer when it receives a notification from Redfish event service.
## A.4 Flow of monitoring tasks related to asynchronous operations (polling method)
diff --git a/media/image25.png b/media/image25.png
new file mode 100644
index 0000000000000000000000000000000000000000..1d167d83316faa37ee374756aca32b3ebcf3ea1a
Binary files /dev/null and b/media/image25.png differ
diff --git a/media/image26.png b/media/image26.png
new file mode 100644
index 0000000000000000000000000000000000000000..b6ec16caf32c23f55f1631a58e8dbd64f3290fa7
Binary files /dev/null and b/media/image26.png differ
diff --git a/media/image27.png b/media/image27.png
new file mode 100644
index 0000000000000000000000000000000000000000..b28f63125c5ed7bdb34d7b421e8cd11f7f5a40c6
Binary files /dev/null and b/media/image27.png differ
diff --git a/media/image28.png b/media/image28.png
new file mode 100644
index 0000000000000000000000000000000000000000..301b1a62ce6450fd36fe50a3c01060ca24f82f67
Binary files /dev/null and b/media/image28.png differ
diff --git a/media/image29.png b/media/image29.png
new file mode 100644
index 0000000000000000000000000000000000000000..ae9881070f774fa5b923f4f3ad6e2c57f5faa9b7
Binary files /dev/null and b/media/image29.png differ
diff --git a/media/image30.png b/media/image30.png
new file mode 100644
index 0000000000000000000000000000000000000000..7c0e35ed4b8d9efe9d5303a7b3c9d64a09566fb9
Binary files /dev/null and b/media/image30.png differ
diff --git a/media/image31.png b/media/image31.png
new file mode 100644
index 0000000000000000000000000000000000000000..bee7288269a9291a5a0f0c87622dcc1fd7f738f8
Binary files /dev/null and b/media/image31.png differ
diff --git a/uml/Clause9/async-perf-report.txt b/uml/Clause9/async-perf-report.txt
new file mode 100644
index 0000000000000000000000000000000000000000..318d973d48a65a32e111ff652056003d191fc8b8
--- /dev/null
+++ b/uml/Clause9/async-perf-report.txt
@@ -0,0 +1,19 @@
+@startuml
+skinparam defaultFontName "Arial"
+skinparam defaultFontSize 11
+participant "API consumer" as cli
+participant "PIM" as srv
+
+note over cli, srv
+Precondition: The API consumer has previously created a subscription
+containing a PmJob to receive performance reports asynchronously.
+end note
+note over srv
+Performance report is generated
+according to the configured PmJob
+end note
+autonumber
+cli <- srv: POST {NotificationTargetURI} (Event)
+autonumber stop
+
+@enduml
diff --git a/uml/Clause9/create-pm-object.txt b/uml/Clause9/create-pm-object.txt
new file mode 100644
index 0000000000000000000000000000000000000000..7a4f0fd0b5c8630557ebadcdc9301ec1249b67f2
--- /dev/null
+++ b/uml/Clause9/create-pm-object.txt
@@ -0,0 +1,19 @@
+@startuml
+skinparam defaultFontName "Arial"
+skinparam defaultFontSize 11
+ participant "API consumer" as cli
+ participant "PIM" as srv
+ autonumber
+ cli -> srv: POST ()
+alt Asynchronous Operation
+ cli <- srv: 202 Accepted
+else Synchronous Operation
+ srv -> srv: Creates individual\nPM object
+ cli <- srv: 201 Created ()
+ autonumber stop
+end
+ note over cli, srv
+ Postcondition: Upon successful completion of the synchronous operation or of the corresponding task
+ in case of asynchronous operation, the individual PM object has been created.
+ end note
+@enduml
\ No newline at end of file
diff --git a/uml/Clause9/delete-pm-object.txt b/uml/Clause9/delete-pm-object.txt
new file mode 100644
index 0000000000000000000000000000000000000000..ce94f7b59f3a2714064983bffc40ee8fe65ff691
--- /dev/null
+++ b/uml/Clause9/delete-pm-object.txt
@@ -0,0 +1,22 @@
+@startuml
+skinparam defaultFontName "Arial"
+skinparam defaultFontSize 11
+ participant "API consumer" as cli
+ participant "PIM" as srv
+ note over cli, srv
+ Precondition: The individual PM object has been previously created.
+ end note
+ autonumber
+ cli -> srv: DELETE
+alt Asynchronous Operation
+ cli <- srv: 202 Accepted
+else Synchronous Operation
+ srv -> srv: Deletes individual\nPM object
+ cli <- srv: 204 No Content / 200 OK ()
+ autonumber stop
+end
+ note over cli, srv
+ Postcondition: Upon successful completion of the synchronous operation or of the corresponding task in
+ case of asynchronous operation, the individual PM object has been deleted.
+ end note
+@enduml
\ No newline at end of file
diff --git a/uml/Clause9/modify-pm-object.txt b/uml/Clause9/modify-pm-object.txt
new file mode 100644
index 0000000000000000000000000000000000000000..f07ba7145d2c455df7e703269407328b79b04426
--- /dev/null
+++ b/uml/Clause9/modify-pm-object.txt
@@ -0,0 +1,22 @@
+@startuml
+skinparam defaultFontName "Arial"
+skinparam defaultFontSize 11
+ participant "API consumer" as cli
+ participant "PIM" as srv
+ note over cli, srv
+ Precondition: The individual PM object has been previously created.
+ end note
+ autonumber
+ cli -> srv: PATCH (PatchSet)
+alt Asynchronous Operation
+ cli <- srv: 202 Accepted
+else Synchronous Operation
+ srv -> srv: Modifies individual\nPM object
+ cli <- srv: 200 OK () / 204 No Content
+ autonumber stop
+end
+ note over cli, srv
+ Postcondition: Upon successful completion of the synchronous operation or of the corresponding task
+ in case of asynchronous operation, the individual PM object has been modified.
+ end note
+@enduml
\ No newline at end of file
diff --git a/uml/Clause9/query-performance-reports.txt b/uml/Clause9/query-performance-reports.txt
new file mode 100644
index 0000000000000000000000000000000000000000..e3d871df812bcca56a90bd928ea9b1cd663c1443
--- /dev/null
+++ b/uml/Clause9/query-performance-reports.txt
@@ -0,0 +1,21 @@
+@startuml
+skinparam defaultFontName "Arial"
+skinparam defaultFontSize 11
+ participant "API consumer" as cli
+ participant "PIM" as srv
+
+ note over cli, srv
+ Precondition: One or more individual performance reports have been created.
+ end note
+
+ alt Query information about multiple performance reports
+ autonumber
+ cli -> srv: GET .../redfish/v1/TelemetryService/MetricReports
+ srv -> cli: 200 OK (MetricReportCollection)
+ else Query information about individual performance report
+ cli -> srv: GET .../redfish/v1/TelemetryService/MetricReports/{MetricReportId}
+ srv -> cli: 200 OK (MetricReport)
+ autonumber stop
+
+end
+@enduml
diff --git a/uml/Clause9/query-pm-objects.txt b/uml/Clause9/query-pm-objects.txt
new file mode 100644
index 0000000000000000000000000000000000000000..a283689504a61ab5823cef0cb470081fcea3fadd
--- /dev/null
+++ b/uml/Clause9/query-pm-objects.txt
@@ -0,0 +1,21 @@
+@startuml
+skinparam defaultFontName "Arial"
+skinparam defaultFontSize 11
+ participant "API consumer" as cli
+ participant "PIM" as srv
+
+ note over cli, srv
+ Precondition: One or more individual PM objects have been created.
+ end note
+
+ alt Query information about multiple PM objects
+ autonumber
+ cli -> srv: GET
+ srv -> cli: 200 OK ()
+ else Query information about individual PM object
+ cli -> srv: GET
+ srv -> cli: 200 OK ()
+ autonumber stop
+
+end
+@enduml
diff --git a/uml/Clause9/replace-pm-object.txt b/uml/Clause9/replace-pm-object.txt
new file mode 100644
index 0000000000000000000000000000000000000000..400b006173071a6925cdcdc7441e07a8db244fad
--- /dev/null
+++ b/uml/Clause9/replace-pm-object.txt
@@ -0,0 +1,22 @@
+@startuml
+skinparam defaultFontName "Arial"
+skinparam defaultFontSize 11
+ participant "API consumer" as cli
+ participant "PIM" as srv
+ note over cli, srv
+ Precondition: The individual PM object has been previously created.
+ end note
+ autonumber
+ cli -> srv: PUT ()
+alt Asynchronous Operation
+ cli <- srv: 202 Accepted
+else Synchronous Operation
+ srv -> srv: Replaces individual\nPM object
+ cli <- srv: 200 OK () / 204 No Content
+ autonumber stop
+end
+ note over cli, srv
+ Postcondition: Upon successful completion of the synchronous operation or of the corresponding
+ task in case of asynchronous operation, the individual PM object has been replaced.
+ end note
+@enduml
\ No newline at end of file