MetricProperties to follow RFC6901 JSON fragment rules ?

With respect to the query raised in the Service Validator Git Repo (github.com/DMTF/Redfish-Service-Validator/issues/341), @odata.id and MemberId attributes under Chassis Power/Thermal URIs neeeds to have incremental array index values, starting from 0. Also, we have an attribute named "SensorNumber" which acts as the identifier to the Sensor.


"Fans":
[
{
"@odata.id": "/redfish/v1/Chassis/Self/Thermal#/Fans/0",
"LowerThresholdCritical": 1600,
"LowerThresholdFatal": 100,
"LowerThresholdNonCritical": 1900,
"MaxReadingRange": 25500,
"MemberId": "0",
"MinReadingRange": 0,
"Name": "System Fan 1",
"Oem": {
"Ami": {
"@odata.type": "#AMIChassisPowerThermal.v1_0_0.AMIChassisPowerThermal",
"OwnerLUN": 0
}
},
"PhysicalContext": "Fan",
"Reading": 10500,
"ReadingUnits": "RPM",
"RelatedItem@odata.count": 0,
"SensorNumber": 48,
"Status": {
"Health": "OK",
"State": "Enabled"
},
"UpperThresholdCritical": 23000,
"UpperThresholdFatal": 25500,
"UpperThresholdNonCritical": 22000
},
{
"@odata.id": "/redfish/v1/Chassis/Self/Thermal#/Fans/1",
"LowerThresholdCritical": 1600,
"LowerThresholdFatal": 100,
"LowerThresholdNonCritical": 1900,
"MaxReadingRange": 25500,
"MemberId": "1",
"MinReadingRange": 0,
"Name": "System Fan 2",
"Oem": {
"Ami": {
"@odata.type": "#AMIChassisPowerThermal.v1_0_0.AMIChassisPowerThermal",
"OwnerLUN": 0
}
},
"PhysicalContext": "Fan",
"Reading": 10700,
"ReadingUnits": "RPM",
"RelatedItem@odata.count": 0,
"SensorNumber": 50,
"Status": {
"Health": "OK",
"State": "Enabled"
},
"UpperThresholdCritical": 23000,
"UpperThresholdFatal": 25500,
"UpperThresholdNonCritical": 22000
},
.....
]

Now, if we use the same array based Index values under the MetricProperties attribute in MetricDefinitons Instance Resource as mentioned below,

"MetricProperties": [
"/redfish/v1/Chassis/Self/Thermal#/Fans/0/ReadingRPM",
"/redfish/v1/Chassis/Self/Thermal#/Fans/1/ReadingRPM",
"/redfish/v1/Chassis/Self/Thermal#/Fans/2/ReadingRPM",
"/redfish/v1/Chassis/Self/Thermal#/Fans/3/ReadingRPM",
"/redfish/v1/Chassis/Self/Thermal#/Fans/4/ReadingRPM",
"/redfish/v1/Chassis/Self/Thermal#/Fans/5/ReadingRPM"
],


it would be difficult for the user to correlate as to which sensor is actually being referred to

• in the MetricReports being generated,


• in the Telemetry Log Entries being generated,


• in the Event Notifications being generated, etc.

since the indexes will be like 0,1,2,3,4,5,etc. whereas the Actual Sensor Numbers will be entirely different.


So, in order to make the correlation of the sensors between Telemetry Service MetricDefinitions and Chassis Power/Thermal URIs more user friendly, we have introduced a new AMI OEM attribute, named OwnerLUN.

The OwnerLUN attribute is used in combination with SensorNumber attribute to display the Sensors under the MetricProperties attribute. This attribute can be used to diferentiate sensors with identical Sensor numbers but different LUN numbers. Under Telemetry Service MetricDefinitions URI, each value under “MetricProperties” attribute depicts either a Temperature/Fan/Voltage Sensor and each of them is represented as a combination of its Sensor Number and Owner LUN Number.

For e.g., If a Fan Sensor has Sensor Number as 48 and LUN Number as 0, then it will be displayed under the MetricProperties attribute as a combination of its Sensor Number and Owner LUN Number as mentioned below:

/redfish/v1/Chassis/Self/Thermal#/Fans/48_0/ReadingRPM


{

"@odata.context": "/redfish/v1/$metadata#MetricDefinition.MetricDefinition",

"@odata.etag": "\"1638947730\"",

"@odata.id": "/redfish/v1/TelemetryService/MetricDefinitions/Fan_Reading",

"@odata.type": "#MetricDefinition.v1_0_3.MetricDefinition",

"Accuracy": 5,

"Id": "Fan_Reading",

"Implementation": "PhysicalSensor",

"IsLinear": true,

"MetricDataType": "Integer",

"MetricProperties": [

"/redfish/v1/Chassis/Self/Thermal#/Fans/58_0/ReadingRPM",

"/redfish/v1/Chassis/Self/Thermal#/Fans/54_0/ReadingRPM",

"/redfish/v1/Chassis/Self/Thermal#/Fans/48_0/ReadingRPM",

"/redfish/v1/Chassis/Self/Thermal#/Fans/52_0/ReadingRPM",

"/redfish/v1/Chassis/Self/Thermal#/Fans/56_0/ReadingRPM",

"/redfish/v1/Chassis/Self/Thermal#/Fans/50_0/ReadingRPM"

],

"MetricType": "Numeric",

"Name": "Fan Reading",

"Precision": 3,

"Units": "RPM"

}


But as per the DMTF Schema for Metric Definitions MetricDefinition.v1_1_1.MetricDefinition, the value of the MetricProperties attribute shall list a set of URIs and the property identifiers portion of each URI shall follow RFC6901-defined JSON fragment notation rules.


"MetricProperties":
{
"description": "The list of URIs with wildcards and property identifiers that this metric definition defines. If a URI has wildcards, the wildcards are substituted as specified in the Wildcards array property.",
"format": "uri-reference",
"items": {
"type": [
"string",
"null"
]
},
"longDescription": "This array property shall list the URIs with wildcards and property identifiers that this metric defines. A set of curly braces shall delimit each wildcard in the URI. The corresponding entry in the Wildcard property shall replace each wildcard. After a URI with wildcards replaces its wildcards, it shall identify a resource property to which the metric definition applies. The property identifiers portion of the URI shall follow RFC6901-defined JSON fragment notation rules.",
"readonly": false,
"type": "array"
}


So, is it good enough to continue with the existing implementation where the property identifiers portion of the URI under MetricProperties attribute do not necessarily follow JSON fragment notation rules

or

is it mandatory to follow JSON fragment notation rules for MetricProperties attribute ?