Inconsistency in USP spec regarding the Get message

[JacobsJohan]

Description

There is an inconsistency in the examples for the Get message. It is not clear to me how many resolved_paths are expected for a requested_path when the requested_path points to an object with sub-objects. Quoting the USP spec on this topic:

For each resolved Path Name, a ResolvedPathResult message is given in the Response. This ResolvedPathResult contains the resolved_path, followed by a list of parameters (result_params) of both the resolved_path Object and all of its sub-objects, plus their values.

Based on this I would think that the sub-objects of a resolved_path are part of the parameters that belong to that resolved_path. This is how it's done in the first example where the Stats object is a sub-object of Device.WiFi.SSID.1..

Pasting the example here for clarity:

    Get {
      param_paths {
        "Device.WiFi.SSID.[SSID=="Homenetwork"&&BSSID==00:11:22:33:44:55]."
      }
    }

In response to this request the Agent returns all parameters, plus sub-Objects and their parameters, of the addressed instance. The Agent returns this data in the Get response using a field for each of the requested paths. In this case:

    GetResp {
        req_path_results {
        requested_path: "Device.WiFi.SSID.[SSID=="Homenetwork"&&BSSID=00:11:22:33:44:55]."
        err_code : 0
        err_msg :
        resolved_path_results {
          resolved_path : "Device.WiFi.SSID.1."
          result_params {
            {
              key: "Enable"
              value: "True"
            }
            {
              key: "Status"
              value: "Up"
            }
            {
              key: "Name"
              value: "Home Network"
            }
            {
              key: "LastChange"
              value: "864000"
            }
            {
              key: "BSSID"
              value: "00:11:22:33:44:55"
            }
            {
              key: "Stats.BytesSent"
              value: "24901567"
            }
            {
              key: "Stats.BytesReceived"
              value: "892806908296"
            }

            (etc.)
          }
        }
      }
    }

This example seems to be in line with the spec, however a bit further there is another get example with a requested_path for "Device.LocalAgent.MTP.[Alias=="CoAP-MTP1"]." (and another path). In this case there are 3 resolved_paths for the request:

• "Device.LocalAgent.MTP.5156."
• "Device.LocalAgent.MTP.5156.CoAP."
• "Device.LocalAgent.MTP.5156.STOMP."

However I would expect the CoAP. and STOMP. sub-objects to be part of the parameters of "Device.LocalAgent.MTP.5156." similar to the Stats object being a parameter of "Device.WiFi.SSID.1." in the previous example.

Pasting full example here for easy reference:

Get Request:

header {
  msg_id: "5721"
  msg_type: GET
}
body {
  request {
    get {
      param_paths: "Device.LocalAgent.MTP.[Alias=="CoAP-MTP1"]."
      param_paths: "Device.LocalAgent.Subscription.[ID=="boot-1"&&Recipient=="Device.LocalAgent.Controller.1"].Enable"
    }
  }
}

Get Response:

header {
  msg_id: "5721"
  msg_type: GET_RESP
}
body {
  response {
    get_resp {
      req_path_results {
        requested_path: "Device.LocalAgent.MTP.[Alias=="CoAP-MTP1"]."
        resolved_path_results {
          resolved_path: "Device.LocalAgent.MTP.5156." {
              {
                key: "Alias"
                value: "CoAP-MTP1"
              }
              {
                key: "Enable"
                value: "False"
              }
              {
                key: "EnableMDNS"
                value: "True"
              }
              {
                key: "Protocol"
                value: "CoAP"
              }
              {
                key: "Status"
                value: "Inactive"
              }
            }
          }

        resolved_path_results {
          resolved_path: "Device.LocalAgent.MTP.5156.CoAP."
          result_params {
            {
              key: "CheckPeerID"
              value: "False"
            }
            {
              key: "EnableEncryption"
              value: "True"
            }
            {
              key: "Host"
              value: "127.0.0.1"
            }
            {
              key: "IsEncrypted"
              value: "False"
            }
            {
              key: "Path"
              value: "/e/agent"
            }
            {
              key: "Port"
              value: "5684"
            }
            {
              key: "ValidatePeerCertificate"
              value: "True"
            }
          }
        }
        resolved_path_results {
          resolved_path: "Device.LocalAgent.MTP.5156.STOMP."
          result_params {
            {
              key: "Destination"
            }
            {
              key: "Reference"
            }
          }
        }
      }
      req_path_results {
        requested_path: "Device.LocalAgent.Subscription.[ID=="boot-1"&&Recipient=="Device.LocalAgent.Controller.1"].Enable"
        resolved_path_results {
          resolved_path: "Device.LocalAgent.Subscription.6629."
          result_params {
            key: "Enable"
            value: "True"
          }
        }
      }
    }
  }
}

Could you let me know if I am missing something here or if there is indeed an error in the examples? In case there is an error, could you let me know which of the 2 options is the correct one?

Thank you for your time.

[therealprof]

👋 Interesting ambiguity you found there!

There's also TP-469 (which is a test plan for TR-369) and if you have a look at https://usp-compliance.broadband-forum.org/#get-message-with-object-path you can the expected result for such a path traversing as per the test plan.

[JacobsJohan]

So based on the expected test result, the 2nd example shows the correct implementation.

Additional resolved_path_results exist for each of the sub-objects of Device.LocalAgent., with result_params containing the keys and values of each sub-object’s parameters.

Could this be updated in the USP spec to avoid confusion in the future?

[helpatbbf]

Hi Johan,

Thank you for your suggestion. I have sent you an email on submitting this change as a contribution to the USP spec. If you have any questions, please feel free to reply to my email or reach out to info@broadband-forum.org. We appreciate your contribution. Thank You!

Rhonda Heier Broadband Forum

[helpatbbf]

Closing this issue. If you have any questions or comments, please contact the Broadband Forum at info@broadband-forum.org