Structured data and use of wildcards in Get results in ambiguous results

[KookyMonster]

Sections 2.3.1 and 2.4.3 suggest that that data returned should begin at the requested data element omitting all parent nodes (eg. the example json_val contents for path "/a/b[name=b1]/c" under 2.3.1). If however one of the parent nodes is wildcarded such as the case where you want the oper-status of all interfaces in the "gNMI Path Conventions" document this would result in ambiguously returning a series of "UP"s and "DOWN"s without knowing which state corresponds to which interface (since the "name" element was considered a parent of the requested path it should be omitted per 2.3.1 and 2.4.3. Is my interpretation of these sections correct?

[robshakir]

I'm not sure that I understand the question here.

In general, we can consider that a subscription to (using the PathElem syntax):

path: <
  elem: <
    name: "interfaces"
  >
  elem: <
    name: "interface"
    key: <
      key: "name"
      value: "*"
    >
  >
  elem: <
    name: "state"
  >
  elem: <
    name: "oper-status"
  >
>

Which corresponds to /interfaces/interface[name=*]/state/oper-status is sent, then the Notifications that are returned must have the complete path specified within them. Therefore if some interface eth0 results in a Notification being sent, then the path specified will be:

path: <
  elem: <
    name: "interfaces"
  >
  elem: <
    name: "interface"
    key: <
      key: "name"
      value: "eth0"
    >
  >
  elem: <
    name: "state"
  >
  elem: <
    name: "oper-status"
  >
>

With a value of UP or DOWN etc.

2.3.1 is not really relevant here, because it refers to aggregated data, which is not allowed unless explicitly marked in the schema. However, even if it were relevant, the path would still specify the absolute path (not the wildcarded path) for each transmitted Notification.

2.4.3 specifies that we have explicit recursion from a specified path for Get and Subscribe. I'm not clear that I understand the discussion point here.

[KookyMonster]

Thanks for the reply Rob, I think I understand now. I must have overlooked the part where a Notification can have multiple "Update" messages within it, allowing us to expand the wildcarded request path into fully-specified paths in the response. Just to make sure my interpretation is now in line with what you expect, is this what a request/response would look like with a wildcarded path?

Request:

path: <
  elem: <
        name: "oc-if:interfaces"
    >
    elem: <
        name: "interface"
        key: <
            key: "name"
            value: "*"
        >
    >
    elem: <
        name: "state"
    >
    elem: <
        name: "oper-status"
    >
>

Respnse:

Notification: <
    Update: <
        path: <
            elem: <
                name: "oc-if:interfaces"
            >
            elem: <
                name: "interface"
                key: <
                    key: "name"
                    value: "GigabitEthernet1/1/1"
                >
            >
            elem: <
                name: "state"
            >
            elem: <
                name: "oper-status"
            >
        >
        val: <
            string_val: "UP"
        >
    >
    Update: <
        path: <
            elem: <
                name: "oc-if:interfaces"
            >
            elem: <
                name: "interface"
                key: <
                    key: "name"
                    value: "GigabitEthernet1/1/2"
                >
            >
            elem: <
                name: "state"
            >
            elem: <
                name: "oper-status"
            >
        val: <
            string_val: "UP"
        >
    >
    Update: <
        path: <
            elem: <
                name: "oc-if:interfaces"
            >
            elem: <
                name: "interface"
                key: <
                    key: "name"
                    value: "GigabitEthernet1/1/3"
                >
            >
            elem: <
                name: "state"
            >
            elem: <
                name: "oper-status"
            >
        val: <
            string_val: "DOWN"
        >
    >
>

[robshakir]

Yes -- this looks correct (with the exception that gNMI paths do not use the namespace prefix).

[KookyMonster]

Ok great.

With respect to gNMI paths not using a namespace prefix, how would one disambiguate between root elements in different namespaces? Is the intention that gNMI can only be used to access OpenConfig models, and the OpenConfig models will be defined in such a way as to avoid ambiguous root elements? If this is the case is there any reason that gNMI should be artificially restricted to only operate on OpenConfig models and not the entire set of available models on a device (eg. IETF models, vendor-specific models etc.)?