Expectations for the `openconfig` origin.

[robshakir]

 * (M) docs/implementation-guidance/openconfig-gnmi-guidelines.md
  - This change adds a document that covers the expectations for the
    openconfig origin in gNMI. These clarifications allow for
    simplifications to be made for some functionality.

This document is to be checked in as an addendum to the models. PTAL :-)

[OpenConfigBot]

Compatibility Report for commit 63113b51ab6512c651722bcd92b962dc94ff5dce: ⛔ yanglint@SO 1.10.17

[robshakir]

@dplore Could you PTAL here, I'd like to check this in if we can as it's been referenced a few times recently.

[cfyo]

Is this saying then that if I have a multi-vendor platform and want to perform a gNMI subscription to /interfaces/interface to each but if one vendor has created a vendor-specific node name for augmentations for that path I need to do a different gNMI subscription depending on the vendor with that addition. And if all vendors have one then each vendor has a slightly different gNMI subscription that must be used. This seems to defeat the agnostic vision of OC and operators now will have to keep track of not only OC path but potential vendor specific nodes used in it. I would suggest requiring the vendor must use the same vendor-specific node name across all OC paths at minimum so it doesn't have to become more complicated.

[dplore]

Is this saying then that if I have a multi-vendor platform and want to perform a gNMI subscription to /interfaces/interface to each but if one vendor has created a vendor-specific node name for augmentations for that path I need to do a different gNMI subscription depending on the vendor with that addition. And if all vendors have one then each vendor has a slightly different gNMI subscription that must be used. This seems to defeat the agnostic vision of OC and operators now will have to keep track of not only OC path but potential vendor specific nodes used in it. I would suggest requiring the vendor must use the same vendor-specific node name across all OC paths at minimum so it doesn't have to become more complicated.

Hi @cfyo, this PR formalizes a requirement:

when `origin` YANG extension is set to `openconfig` and in gNMI when the `origin` field is set to 
`openconfig` or an empty string, all paths MUST be unique when considering only the node 
name, and **NOT** prefixing this name with a module namespace.

The intent of this clarification is to safely permit referencing OC paths without using prefixes.

With this requirement in place, if/when a vendor augments an openconfig model using a vendor proprietary model, the vendor will need to present unique paths in order to coexist with openconfig or their model may be in conflict with openconfig.

Unless the model is checked into the openconfing/public repository, it is not openconfig compliant. If a vendor deviates or augments openconfig the augment is a vendor model, not openconfig.

We don't want vendor augments to openconfig. Instead we should encourage a PR to be submitted to add the desired models to openconfig. But yang defines augment and deviate as features, so it is possible to 'extend' openconfig with proprietary models.

[dplore]

Here is an example of mixed openconfig and cli schema in a single gNMI SetRequest:

https://github.com/openconfig/reference/blob/master/rpc/gnmi/mixed-schema.md#example-openconfig-and-cli-data

[wenovus]

Hi I'm wondering if we should specify, for the "openconfig" origin, whether to always omit the module names from the path when streaming gNMI? If so shall we add it?

Another thing we might add is: "anything that is in the OpenConfig origin is expected to pass the OpenConfig linter checks (OpenConfig style guide), including augments"