diff --git a/designs/telemetry.md b/designs/telemetry.md
index af313a3..659b17a 100644
--- a/designs/telemetry.md
+++ b/designs/telemetry.md
@@ -24,18 +24,17 @@
 for exposing platform telemetry over the network.
 * OpenBMC platform telemetry shall leverage the
 [OpenBMC sensors architecture implementation][2].
-* OpenBMC platform telemetry shall implement a service, called Monitoring
-Service to deal with metrics report and trigger management. This service
-is described later in this document.
+* OpenBMC platform telemetry shall implement a service, called Telemetry to deal
+with metrics report and trigger management. This service is described later in
+this document.
 * Although we use the [hwmon][3] to gather readings from physical sensors, this
-architecture does not depend on it, because the Monitoring Service component
+architecture does not depend on it, because the Telemetry service component
 relies on the [OpenBMC D-Bus sensors][2].
 
 
 ## Requirements
-* [OpenBMC D-Bus sensors][2] support. This is also design limitation, since
-the Monitoring Service requires telemetry sources to be implemented as
-D-Bus sensors.
+* [OpenBMC D-Bus sensors][2] support. This is also design limitation, since the
+Telemetry service requires telemetry sources to be implemented as D-Bus sensors.
 
 
 ## Proposed Design
@@ -53,9 +52,9 @@
 
 ```ascii
    +--------------+               +----------------+     +-----------------+
-   |hwmon|        |               |Dbus sensors|   |     |Monitoring|      |
-   +-----/        |               +------------/   |     |service   |      |
-   |              +--filesystem--->                |     +----------/      |
+   |hwmon|        |               |Dbus sensors|   |     |Telemetry|       |
+   +-----/        |               +------------/   |     +---------/       |
+   |              +--filesystem--->                |     |                 |
    |              |               |                |     |                 |
    +--------------+               +--------^-------+     +--------^--------+
                                            |                      |
@@ -99,9 +98,9 @@
 [Redfish Telemetry Model][1]. Metric report definitions uses Redfish sensors
 URIs for metric report creation. Those sensors are also used to get
 URI->D-Bus sensor mapping. Redfish Telemetry Service acts as presentation
-layer for the telemetry, while Monitoring Service is responsible for gathering
-metrics from D-Bus sensors and exposing them as D-Bus objects. Monitoring
-Service supports different monitoring modes (periodic, on change and on demand)
+layer for the telemetry, while Telemetry service is responsible for gathering
+metrics from D-Bus sensors and exposing them as D-Bus objects. Telemetry
+service supports different monitoring modes (periodic, on change and on demand)
 along with aggregated operations:
 * SINGLE - current reading value
 * AVERAGE - average value over defined time period
@@ -112,17 +111,17 @@
 The time period for calculating aggregated is taken from the Redfish Metric
 Definition resource for each sensor's metric.
 
-Monitoring Service supports creating and managing metric report, which may
+Telemetry service supports creating and managing metric report, which may
 contain single or multiple metrics from sensors. This metric report is mapped
 to Metric Report for the Redfish Telemetry Service.
 
 The diagram below shows the flows for creation and update of metric report.
 
 ```ascii
-+----+              +------+              +----------+                +-------+
-|User|              |bmcweb|              |Monitoring|                | D-Bus |
-+-+--+              +--+---+              | Service  |                |Sensors|
-  |                    |                  +----------+                +---+---+
++----+              +------+              +---------+                 +-------+
+|User|              |bmcweb|              |Telemetry|                 | D-Bus |
++-+--+              +--+---+              +----+----+                 |Sensors|
+  |                    |                       |                      +---+---+
   |                    |                       |                          |
 +-----------------------------------------------------------------------------+
 |Metric report definition flow|                |                          |   |
@@ -266,18 +265,18 @@
 
 The Redfish implementation in bmcweb is stateless, thus it is not able to
 store metric reports. All operations on metric reports shall be done in
-the Monitoring Service. Sending metric report as SSE or push-style events
+the Telemetry service. Sending metric report as SSE or push-style events
 shall be done via the [Redfish Event Service][6]. It is marked as optional
 because metric report does not have to be configured for pushing its data
 through the event.
 
-In case of on demand metric report update, Monitoring Service performs no
+In case of on demand metric report update, Telemetry service performs no
 additional sensor readings because it already has the latest values, since
 they are updated on PropertiesChanged signal from the D-Bus sensors.
 
-**Monitoring service on [D-Bus][4]**
+**Telemetry service on [D-Bus][4]**
 
-Monitoring service exposes specific interfaces on D-Bus. One of them will be
+Telemetry service exposes specific interfaces on D-Bus. One of them will be
 used for reading report management. The second one will be used for triggers
 management.
 
@@ -286,15 +285,15 @@
 The reading report management D-Bus object:
 
 ```ascii
-xyz.openbmc_project.MonitoringService.ReportsManagement
-/xyz/openbmc_project/MonitoringService/Reports
+xyz.openbmc_project.Telemetry.ReportsManagement
+/xyz/openbmc_project/Telemetry/Reports
 ```
 The ```ReportsManagement``` supports the following interface apart from
 standard D-Bus interface.
 
 | Name | Type | Signature | Result/Value | Flags |
 |------|------|-----------|--------------|-------|
-|```xyz.openbmc_project.MonitoringService.ReportsManagement``` | interface | - | - | - |
+|```xyz.openbmc_project.Telemetry.ReportsManagement``` | interface | - | - | - |
 |```.AddReport```                          | method    | ssuas | s | - |
 |```.MaxReports```                         | property  | u | 50 | emits-change |
 |```.PollRateResolution```                 | property  | u | 100 | emits-change |
@@ -306,7 +305,7 @@
 | Argument | Type | Description |
 |----------|------|-------------|
 | Prefix | string | Defines prefix for report so it will be "<prefix\><randomString\>" i.e.: for prefix "test" -> testqrapndyY |
-| ReportingType | string | Reporting type: <br> "xyz.openbmc_project.MonitoringService.Metric.Periodic" - For periodic update "xyz.openbmc_project.MonitoringService.Metric.OnChange" - For update when value changes "xyz.openbmc_project.MonitoringService.Metric.OnRequest" - For update when user requests data |
+| ReportingType | string | Reporting type: <br> "xyz.openbmc_project.Telemetry.Metric.Periodic" - For periodic update "xyz.openbmc_project.Telemetry.Metric.OnChange" - For update when value changes "xyz.openbmc_project.Telemetry.Metric.OnRequest" - For update when user requests data |
 | ScanPeriod | uint32_t | Scan period used when Periodic type is set (in milliseconds) |
 | MetricsParams | array of structures | Collection of metric parameters.  |
 
@@ -319,13 +318,13 @@
 
 The ```ScanPeriod``` is defined per report, thus all sensors listed in the MetricsParams
 collection will be scanned wit the same frequency. Also the ReportingType is
-defined per report. In case when *xyz.openbmc_project.MonitoringService.Metric.OnChange*
+defined per report. In case when *xyz.openbmc_project.Telemetry.Metric.OnChange*
 ReportingType was defined, metric report will emit signal when at least one
 reading has changed.
 
 The ```AddReport``` method returns:
 ```ascii
-String for created report - ie. '/xyz/openbmc_project/MonitoringService/Reports/testqrapndyY'
+String for created report - ie. '/xyz/openbmc_project/Telemetry/Reports/testqrapndyY'
 ```
 
 Such created metric report implements the following interfaces, methods and
@@ -335,7 +334,7 @@
 |------|------|-----------|--------------|-------|
 |```xyz.openbmc_project.Object.Delete```   | interface | - | - | - |
 |```.Delete```                             | method    | - | - | - |
-|```xyz.openbmc_project.MonitoringService.Report``` | interface | - | - | - |
+|```xyz.openbmc_project.Telemetry.Report``` | interface | - | - | - |
 |```.Update```                             | method    | - | - | - |
 |```.ReadingParameters```                  | property  | a(sos) | 1 "/" | emits-change writable |
 |```.Readings```                           | property  | a(svs) | 0 | emits-change read-only |
@@ -369,25 +368,25 @@
 The Delete method results in deleting the whole metric report.
 
 The ```MaxReports``` property of
-the ```xyz.openbmc_project.MonitoringService.ReportsManagement``` interface
-contains the max number of metric reports supported by the Monitoring Service.
-This property is added to be compliant with the Redfish Telemetry Service
-schema, that contains ```MaxReports``` property.
+the ```xyz.openbmc_project.Telemetry.ReportsManagement``` interface contains the
+max number of metric reports supported by the Telemetry service. This property
+is added to be compliant with the Redfish Telemetry Service schema, that
+contains ```MaxReports``` property.
 
 **Trigger management**
 
 The trigger management D-Bus object:
 
 ```ascii
-xyz.openbmc_project.MonitoringService.TriggersManagement
-/xyz/openbmc_project/MonitoringService/Triggers
+xyz.openbmc_project.Telemetry.TriggersManagement
+/xyz/openbmc_project/Telemetry/Triggers
 ```
 The ```TriggersManagement``` supports the following interface apart from
 standard D-Bus interface.
 
 | Name | Type | Signature | Result/Value | Flags |
 |------|------|-----------|--------------|-------|
-|```xyz.openbmc_project.MonitoringService.TriggersManagement``` | interface | - | - | - |
+|```xyz.openbmc_project.Telemetry.TriggersManagement``` | interface | - | - | - |
 |```.AddTrigger```                         | method    | sssv(os) | s | - |
 
 The ```AddTrigger``` method shall be used to create new trigger for the
@@ -397,24 +396,24 @@
 | Argument | Type | Description |
 |----------|------|-------------|
 | Prefix | string | Defines prefix for report so it will be "<prefix\><randomString\>" i.e.: for prefix "test" -> trigger0dfvAgVt6 |
-| ActionType | string | Action type: <br> "xyz.openbmc_project.MonitoringService.Trigger.Log" - For logging to log service "xyz.openbmc_project.MonitoringService.Trigger.Event" - For sending Redfish event "xyz.openbmc_project.MonitoringService.Trigger.Update" - For trigger metric report update |
-| MetricType | string | Metric type: <br> "xyz.openbmc_project.MonitoringService.Trigger.Discrete" - for discrete sensors "xyz.openbmc_project.MonitoringService.Trigger.Numeric" - for numeric sensors |
+| ActionType | string | Action type: <br> "xyz.openbmc_project.Telemetry.Trigger.Log" - For logging to log service "xyz.openbmc_project.Telemetry.Trigger.Event" - For sending Redfish event "xyz.openbmc_project.Telemetry.Trigger.Update" - For trigger metric report update |
+| MetricType | string | Metric type: <br> "xyz.openbmc_project.Telemetry.Trigger.Discrete" - for discrete sensors "xyz.openbmc_project.Telemetry.Trigger.Numeric" - for numeric sensors |
 | TriggerParams | variant | Variant containing structure with either discrete triggers or numeric thresholds. |
 | MetricParam | structure | Structure containing D-Bus sensor's path and unique metric Id and optional D-Bus path to metric report to trigger. |
 
 The ```TriggerParams``` is variant type, which shall contain structure
 depending on the ```MetricType``` value. In case when ```MetricType``` contains
-the ```xyz.openbmc_project.MonitoringService.Trigger.Discrete``` value,
+the ```xyz.openbmc_project.Telemetry.Trigger.Discrete``` value,
  ```TriggerParams``` shall contain structure with discrete triggers.
 When ```MetricType``` contains
-the ```xyz.openbmc_project.MonitoringService.Trigger.Numeric``` value,
+the ```xyz.openbmc_project.Telemetry.Trigger.Numeric``` value,
  ```TriggerParams``` shall contain structure with numeric thresholds.
 
 Discrete triggers structure:
 
 | Field | Type | Description |
 |-------|------|-------------|
-| TriggerCondition | string | Discrete trigger condition: <br> "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Changed" - trigger ocurs when value of metric has changed; <br> "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Specified" - trigger occurs when value of metric becomes one of the values listed in the discrete triggers. |
+| TriggerCondition | string | Discrete trigger condition: <br> "xyz.openbmc_project.Telemetry.Trigger.Discrete.Changed" - trigger ocurs when value of metric has changed; <br> "xyz.openbmc_project.Telemetry.Trigger.Discrete.Specified" - trigger occurs when value of metric becomes one of the values listed in the discrete triggers. |
 | DiscreteTriggers | array of structures | Array of discrete trigger structures. |
 
 Member of DiscreteTriggers array:
@@ -422,7 +421,7 @@
 | Field | Type | Description |
 |-------|------|-------------|
 | TriggerId| string     | Unique trigger Id |
-| Severity | string     | Severity: <br> "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Severity.OK" - normal, "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Severity.Warning" - requires attention, "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Severity.Critical" - requires immediate attention |
+| Severity | string     | Severity: <br> "xyz.openbmc_project.Telemetry.Trigger.Discrete.Severity.OK" - normal, "xyz.openbmc_project.Telemetry.Trigger.Discrete.Severity.Warning" - requires attention, "xyz.openbmc_project.Telemetry.Trigger.Discrete.Severity.Critical" - requires immediate attention |
 | Value | variant    | Value of discrete metric, that constitutes a trigger event. |
 | DwellTime | uint64     | Time in milliseconds that a trigger occurrence persists before the action defined in the ```ActionType``` is performed. |
 
@@ -431,29 +430,29 @@
 
 | Field | Type | Description |
 |-------|------|-------------|
-| ThresholdType | string | Numeric trigger type: <br> "xyz.openbmc_project.MonitoringService.Trigger.Numeric.UpperCritical","xyz.openbmc_project.MonitoringService.Trigger.Numeric.UpperWarning","xyz.openbmc_project.MonitoringService.Trigger.Numeric.LowerCritical","xyz.openbmc_project.MonitoringService.Trigger.Numeric.LowerWarning"|
+| ThresholdType | string | Numeric trigger type: <br> "xyz.openbmc_project.Telemetry.Trigger.Numeric.UpperCritical","xyz.openbmc_project.Telemetry.Trigger.Numeric.UpperWarning","xyz.openbmc_project.Telemetry.Trigger.Numeric.LowerCritical","xyz.openbmc_project.Telemetry.Trigger.Numeric.LowerWarning"|
 | DwellTime | uint64 | Time in milliseconds that a trigger occurrence persists before the action defined in the ```ActionType``` is performed. |
-| Activation | string | Indicates direction of crossing the threshold value that trigger the threshold's action: "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Increasing", "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Decreasing", "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Either" |
+| Activation | string | Indicates direction of crossing the threshold value that trigger the threshold's action: "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Increasing", "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Decreasing", "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Either" |
 | ThresholdValue | variant | Value of reading that will trigger the threshold |
 
 The numeric threshold trigger type meaning:
 
-- "xyz.openbmc_project.MonitoringService.Trigger.Numeric.UpperCritical" -
+- "xyz.openbmc_project.Telemetry.Trigger.Numeric.UpperCritical" -
 indicates the reading is above normal range and requires immediate attention
-- "xyz.openbmc_project.MonitoringService.Trigger.Numeric.UpperWarning" -
+- "xyz.openbmc_project.Telemetry.Trigger.Numeric.UpperWarning" -
 indicates the reading is above normal range and may require attention
-- "xyz.openbmc_project.MonitoringService.Trigger.Numeric.LowerCritical" -
+- "xyz.openbmc_project.Telemetry.Trigger.Numeric.LowerCritical" -
 indicates the reading is below normal range and requires immediate attention
-- "xyz.openbmc_project.MonitoringService.Trigger.Numeric.LowerWarning" -
+- "xyz.openbmc_project.Telemetry.Trigger.Numeric.LowerWarning" -
 indicates the reading is below normal range and may require attention
 
 The numeric threshold activation meaning:
 
-- "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Increasing" -
+- "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Increasing" -
 trigger action when reading is changing from below to above the threshold's value
-- "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Decreasing" -
+- "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Decreasing" -
 trigger action when reading is changing from above to below the threshold's value
-- "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Either" -
+- "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Either" -
 trigger action when reading is crossing the threshold's value in either direction
 described above
 
@@ -463,11 +462,11 @@
 |-------|------|-------------|
 | SensorPath | object path | D-Bus path to sensor, for which trigger is defined. |
 | MetricId   | string | Contains unique metric id, that can be mapped to Redfish MetricId. |
-| ReportPath | object path | D-Bus path to Monitoring Service's reading report which update shall be triggered when trigger condition occurs. This is optional and shall be filled when trigger's ActionType is set to "xyz.openbmc_project.MonitoringService.Trigger.Update". |
+| ReportPath | object path | D-Bus path to Telemetry's reading report which update shall be triggered when trigger condition occurs. This is optional and shall be filled when trigger's ActionType is set to "xyz.openbmc_project.Telemetry.Trigger.Update". |
 
 The ```AddTrigger``` method returns:
 ```ascii
-String for created trigger - ie. '/xyz/openbmc_project/MonitoringService/Triggers/trigger0dfvAgVt6'
+String for created trigger - ie. '/xyz/openbmc_project/Telemetry/Triggers/trigger0dfvAgVt6'
 ```
 Such created trigger implements the following interfaces, methods and
 properties (apart from standard D-Bus interface):
@@ -476,7 +475,7 @@
 |------|------|-----------|--------------|-------|
 |```xyz.openbmc_project.Object.Delete```   | interface | - | - | - |
 |```.Delete```                             | method    | - | - | - |
-|```xyz.openbmc_project.MonitoringService.Trigger``` | interface | - | - | - |
+|```xyz.openbmc_project.Telemetry.Trigger``` | interface | - | - | - |
 |```.MetricType```                         | property | s | One of the MetricType strings | emits-change read-only |
 |```.Triggers```                           | property | {sa{ssvu64}} or a{su64sv} | The structure containing triggers. It depends on ```.MetricType``` property how the structure is defined. | emits-change writable |
 |```.ActionType```                         | property | s | One of ActionType strings | emits-change writable |
@@ -488,12 +487,12 @@
 from numeric to discrete. This also determines how the ```.Triggers``` property
 looks like on D-Bus.
 
-If ```.MetricType``` is equal to "xyz.openbmc_project.MonitoringService.Trigger.Discrete"
+If ```.MetricType``` is equal to "xyz.openbmc_project.Telemetry.Trigger.Discrete"
 then ```.Triggers``` property contains discrete trigger that looks like this:
 
 | Type | Description |
 |------|-------------|
-| string | Discrete trigger condition: <br> "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Changed" - trigger ocurs when value of metric has changed; "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Specified" - trigger occurs when value of metric becomes one of the values listed in the discrete triggers. |
+| string | Discrete trigger condition: <br> "xyz.openbmc_project.Telemetry.Trigger.Discrete.Changed" - trigger ocurs when value of metric has changed; "xyz.openbmc_project.Telemetry.Trigger.Discrete.Specified" - trigger occurs when value of metric becomes one of the values listed in the discrete triggers. |
 | array of structures | Array of discrete trigger structures. |
 
 Member of DiscreteTriggers array:
@@ -501,19 +500,19 @@
 | Type | Description |
 |------|-------------|
 | string     | Unique trigger Id |
-| string     | Severity: <br> "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Severity.OK" - normal, "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Severity.Warning" - requires attention, "xyz.openbmc_project.MonitoringService.Trigger.Discrete.Severity.Critical" - requires immediate attention |
+| string     | Severity: <br> "xyz.openbmc_project.Telemetry.Trigger.Discrete.Severity.OK" - normal, "xyz.openbmc_project.Telemetry.Trigger.Discrete.Severity.Warning" - requires attention, "xyz.openbmc_project.Telemetry.Trigger.Discrete.Severity.Critical" - requires immediate attention |
 | variant    | Value of discrete metric, that constitutes a trigger event. |
 | uint64     | Time in milliseconds that a trigger occurrence persists before the action defined in the ```ActionType``` is performed. |
 
-If ```.MetricType``` is equal to "xyz.openbmc_project.MonitoringService.Trigger.Numeric"
+If ```.MetricType``` is equal to "xyz.openbmc_project.Telemetry.Trigger.Numeric"
 then ```.Triggers``` property contains numeric trigger that is an array of 4 structures
 presented below:
 
 | Type | Description |
 |------|-------------|
-| string | Numeric trigger type: <br> "xyz.openbmc_project.MonitoringService.Trigger.Numeric.UpperCritical", "xyz.openbmc_project.MonitoringService.Trigger.Numeric.UpperWarning", "xyz.openbmc_project.MonitoringService.Trigger.Numeric.LowerCritical", "xyz.openbmc_project.MonitoringService.Trigger.Numeric.LowerWarning"|
+| string | Numeric trigger type: <br> "xyz.openbmc_project.Telemetry.Trigger.Numeric.UpperCritical", "xyz.openbmc_project.Telemetry.Trigger.Numeric.UpperWarning", "xyz.openbmc_project.Telemetry.Trigger.Numeric.LowerCritical", "xyz.openbmc_project.Telemetry.Trigger.Numeric.LowerWarning"|
 | uint64 | Time in milliseconds that a trigger occurrence persists before the action defined in the ```ActionType``` is performed. |
-| string | Indicates direction of crossing the threshold value that trigger the threshold's action: "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Increasing", "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Decreasing", "xyz.openbmc_project.MonitoringService.Trigger.Numeric.Activation.Either" |
+| string | Indicates direction of crossing the threshold value that trigger the threshold's action: "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Increasing", "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Decreasing", "xyz.openbmc_project.Telemetry.Trigger.Numeric.Activation.Either" |
 | variant | Value of reading that will trigger the threshold |
 
 The ```.Metric``` property stores the details about reading, for which trigger was defined.
@@ -523,7 +522,7 @@
 |------------|--------------|
 | object path  | D-Bus path of sensor. This is a path to the sensor, for which reading trigger is defined. |
 | string     | Unique metric Id |
-| object path | D-Bus path of existing reading report. This is required when trigger's action is to update metric report. This path shall point to existing reading report within the Monitoring Service. |
+| object path | D-Bus path of existing reading report. This is required when trigger's action is to update metric report. This path shall point to existing reading report within the Telemetry service. |
 
 **Trigger operations**
 
@@ -531,16 +530,16 @@
 there is a different way of proceeding.
 
 1. For action Log, the event shall
-be logged to the system journal. In this case the Monitoring Service writes
+be logged to the system journal. In this case the Telemetry service writes
 data to system journal using libjournal. The Redfish log service shall then
 retrieve the data by reading system journal. All is shown on the diagram below.
 
 ```ascii
 +---------------------------+
 |bmcweb|                    |         +----------------------+
-+------/    +-----------+-+ |         |Monitoring|           |
-|           |Redfish    | | |         |Service   |           |
-|           |log service| | |         +----------/           |
++------/    +-----------+-+ |         |Telemetry|            |
+|           |Redfish    | | |         +---------/            |
+|           |log service| | |         |                      |
 |           +-----------/ | |         |                      |
 |           |             | |         |                      |
 |           |             | |         |                      |
@@ -562,20 +561,20 @@
        |                                    |
        +------------------------------------+
 ```
-2. For action Event, the Monitoring Service shall send event using the
+2. For action Event, the Telemetry service shall send event using the
 [Redfish Event Service][6] either as push-style event or SSE.
 
-3. For action Update, the Monitoring Service will trigger the update of reading
+3. For action Update, the Telemetry service will trigger the update of reading
 report pointed by it's D-Bus path contained in ReportPath property inside
 the ```.Metric``` structure. The update shall cause the reading report's D-Bus
 object to emit property change signal. This will cause Redfish Metric Report to
 be streamed out if it was configured to do so.
 
-**Telemetry Service Redfish API**
+**Redfish Telemetry Service API**
 
-Telemetry service shall support 2019.1 Redfish schemas for telemetry resources.
-Metric report definitions determines which metrics are to be included in metric
-report. Metric definition is assigned to particular metric type and it
+Redfish Telemetry Service shall support 2019.1 Redfish schemas for telemetry
+resources. Metric report definitions determines which metrics are to be include
+in metric report. Metric definition is assigned to particular metric type and it
 describes how the metric should be interpreted. The following resource schemas
 shall be supported:
 
@@ -634,13 +633,13 @@
 defined to be generated periodically, on demand or on change. Each metric in the
 Metric Report contains the URI to its metric definition and Redfish sensor,
 which reading value is presented. Nevertheless, under this presentation layer,
-Monitoring Service is gathering D-Bus sensors readings and exposing them
+Telemetry is gathering D-Bus sensors readings and exposing them
 in reading reports over D-Bus for the Telemetry Service. Each D-Bus sensor
 is mapped to Redfish sensor.
 
 Below examples of Redfish resources for the Telemetry Service are shown.
 
-The telemetry service Redfish resource example:
+The Telemetry Service Redfish resource example:
 
 ```json
 {
@@ -777,11 +776,11 @@
 **Performance tests**
 
 Performance test were conducted on the AST2500 system with 64 MB flash and
-512 MB RAM. Flash consumption by the Monitoring Service is 197.5 kB. The
+512 MB RAM. Flash consumption by the Telemetry service is 197.5 kB. The
 runtime statistics are shown in the table below. The reading report is
 mapped into single Metric Report. The runtime data is collected for the
-Monitoring Service component only. All reports was created with
-```xyz.openbmc_project.MonitoringService.Metric.OnChange``` property to
+Telemetry component only. All reports was created with
+```xyz.openbmc_project.Telemetry.Metric.OnChange``` property to
 maximize the workload. In the configuration with 50 reports and 50 sensors
 it is about 200 new readings per second, generating 200 reading reports
 per second. The table shows CPU usage and memory usage. The VSZ is the amount
@@ -790,7 +789,7 @@
 stack, as well as anything else it has mapped.
 
 
-| Monitoring service state                         | VSZ  | %VSZ | %CPU |
+| Telemetry service state                          | VSZ  | %VSZ | %CPU |
 |--------------------------------------------------|------|------|------|
 | Idle (0 reports, 0 sensors)                      |5188 B| 1%   | 0%   |
 | 1 report, 1 sensor                               |5188 B| 1%   | 1%   |
@@ -820,22 +819,20 @@
 storage, which may be an issue, when lots of metrics are captured and stored
 to OpenBMC's limited storage space. Also flash wear-out issue may occur, when
 metrics are captured frequently (like once per second).
-* Monitoring Service is directly compatible with Redfish Telemetry
-Service API, which means, that Monitoring Service's reading reports can
-be directly mapped to Redfish Metric Reports.
-* Monitoring Service unifies the way how the BMC's telemetry is exposed over
+* Telemetry service is directly compatible with Redfish Telemetry Service API,
+which means, that Telemetry's reading reports can be directly mapped to Redfish
+Metric Reports.
+* Telemetry service unifies the way how the BMC's telemetry is exposed over
 the Redfish and may be used with multiple front-ends, thus there is no problem
- to add support telemetry over IPMI or any other API.
+to add support telemetry over IPMI or any other API.
 
-Since this design assumes flexibility and modularity, there is no obstacles
-to use collectd in cooperation with Monitoring Service. The one of possible
-configurations is shown on the diagram below.
+Since this design assumes flexibility and modularity, there is no obstacles to
+use collectd in cooperation with Telemetry. The one of possible configurations
+is shown on the diagram below.
 
 ```ascii
    +-----------------+      +-----------------+
-   |                 |      |   Monitoring    |
-   |  D-Bus sensors  |      |    Service      |
-   |                 |      |                 |
+   |  D-Bus sensors  |      |   Telemetry     |
    +--------^--------+      +--------^--------+
             |                        |
             |                        |
@@ -859,11 +856,11 @@
 ```
 Here collectd is used as the source of some set of metrics. It exposes them
 as the D-Bus sensors, which can easily be consumed either by the bmcweb and
-Monitoring Service without any changes in their D-Bus interfaces. In such
-configuration Monitoring Service provides metric reports and triggers
+Telemetry service without any changes in their D-Bus interfaces. In such
+configuration Telemetry service provides metric reports and triggers
 management.
 
-Other possible configuration is to use collectd without the Monitoring Service,
+Other possible configuration is to use collectd without the Telemetry service,
 but in such case, collectd does not provide metric reports and triggers support
 compatible with the Redfish. In such case, Redfish Telemetry Service won't be
 supported or metric reports and triggers support has to be provided by the
@@ -871,7 +868,7 @@
 
 ## Impacts
 This design impacts the architecture of the bmcweb component, since it adds
-the Telemetry Service implementation as a component for the existing
+the Redfish Telemetry Service implementation as a component for the existing
 Redfish API implementation.
 
 ## Testing
@@ -883,7 +880,7 @@
 
 **Unit tests**
 
-The Monitoring Service's code shall be covered by the unit tests. The preferred
+The Telemetry's code shall be covered by the unit tests. The preferred
 framework is the [GTest/GMock][7]. The unit tests shall be ran before code
 change is to be committed to make sure, that nothing is broken in existing
 functionality. Also, when new code is introduced, a new set of unit tests shall
@@ -894,15 +891,14 @@
 
 Functional tests will be divided into two steps.
 
-First step is for testing the
-Monitoring Service metric reports management. Test scenario shall contain
-creating metric report by POSTing proper metric report definition, reading
-metric report (using GET on proper URI) and deleting the metric report. The
-required configuration for such test is D-Bus sensors (at least some of them)
-and bmcweb with Redfish Telemetry Service implemented. The tests shall be
-performed on real hardware. For ease of metric testing, dummy D-Bus sensors
-may be provided to provide specifically prepared metrics. This configuration
-shall also enable testing aggregated operations (MIN, MAX, SUM, AVG).
+First step is for testing the Telemetry metric reports management. Test scenario
+shall contain creating metric report by POSTing proper metric report definition,
+reading metric report (using GET on proper URI) and deleting the metric report.
+The required configuration for such test is D-Bus sensors (at least some of
+them) and bmcweb with Redfish Telemetry Service implemented. The tests shall be
+performed on real hardware. For ease of metric testing, dummy D-Bus sensors may
+be provided to provide specifically prepared metrics. This configuration shall
+also enable testing aggregated operations (MIN, MAX, SUM, AVG).
 
 Second step is to test triggers and events generation. This will require also
 Event Service to be implemented along with Log Service. Tests shall cover all