Closed ngniksnikhil closed 1 year ago
Neither. While YANG has module prefixes to disambiguate models when there are overlaps between them, OpenConfig models in YANG will never rely on the module prefix to provide unique path names. As gNMI supports both OpenConfig and non-OpenConfig schema data where disambiguation might be required, there is a field, 'origin' that is specified to be 'openconfig' for OpenConfig modeled data (the unset value, '', is equivalent as gNMI defaults to OpenConfig) or can be overridden with a vendor specified alternative origin. A given non-OpenConfig origin follows rules subject to a given implementation which may or may not follow the OpenConfig convention.
For OpenConfig paths module name and prefix are elided in gNMI.
/interfaces/interface
I think you are talking about 'origin' which can be shown in the Response. I wanted to know how should I form the request?
e.g. If I use gnmic client, how should I specify path in that request?
which one is the correct format?
Origin is in both the request and response. They will always match. The path should be --path /interfaces/interface because this is an openconfig origin model.
@ngniksnikhil in gnmic origin can be set in the path string like this: --path openconfig:/interfaces/interface...
Hi Carl,
What about non-openconfig models? Say vendor proprietary YANG models, both prefix and full module-name are good to form the subscription path?
Regards Ashutosh
gNMI affords the ability to deliver non-OpenConfig data using an alternate origin. The OpenConfig group does not make stipulations for implementations for alternate models. gNMI could be used even in cases where no YANG models exist, such as for a command-line-interface for mixed-schema configurations if certain options are not modeled but accessible via a CLI. The goal of OpenConfig is to standardize the modeling of common configurations and telemetry. If a given proprietary model likewise had implicit guarantees that name collisions were not possible even when ignoring module name and prefix, it could take advantage of the same terseness in gNMI that OpenConfig models do, or it may not and require the prefix, or it may support both options. That would be up to the implementor.
Thanks, understood and makes sense.
On Thu, Sep 21, 2023 at 6:54 AM Carl Lebsack @.***> wrote:
gNMI affords the ability to deliver non-OpenConfig data using an alternate origin. The OpenConfig group does not make stipulations for implementations for alternate models. gNMI could be used even in cases where no YANG models exist, such as for a command-line-interface for mixed-schema configurations if certain options are not modeled but accessible via a CLI. The goal of OpenConfig is to standardize the modeling of common configurations and telemetry. If a given proprietary model likewise had implicit guarantees that name collisions were not possible even when ignoring module name and prefix, it could take advantage of the same terseness in gNMI that OpenConfig models do, or it may not and require the prefix, or it may support both options. That would be up to the implementor.
— Reply to this email directly, view it on GitHub https://github.com/openconfig/gnmi/issues/153#issuecomment-1728627472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKWIPKFXA3WYOOCJKXPGTM3X3OJOFANCNFSM6AAAAAA47Z3ONA . You are receiving this because you commented.Message ID: @.***>
Thank you guys.
From the documentation given, I was unable to find which should be used as a namespace to distinguish the path. module-name or prefix or any of them.
For a openconfig-intefaces.yang defined as below ` module openconfig-interfaces {
yang-version "1";
// namespace namespace "http://openconfig.net/yang/interfaces";
prefix "oc-if";
`
What is the correct way to create a path for GNMI get request option#1 or 2 or both?
/oc-if:interfaces/oc-if:interface/ /openconfig-interfaces:interfaces/openconfig-interfaces:interface/