Question: Is there a mechanism for tracking the updates to the proto in GNOI?

[AnandJyrm]

Hi all,

Is there some revision/versioning mechanism for GNOI requests similar to the openconfig yang models? Is the version passed as part of the request to the server and what should the expected behavior be if the vendor server supports a lower version?

ex: Vendor server V supports proto P and client uses updated proto P' to send a request to V. What should be the response in the following cases

1. P' has new Request that is not present in P
2. P' has modified existing Request (non backward compatible/evolution)
3. P' has modified existing Request(backward compatible/enhancement)

  oc-ext:openconfig-version "0.20.0";

  revision "2022-08-31" {
    description
      "Add new state data for component CLEI code.";
    reference "0.20.0";
  }

Is gnoi_version the equivalent to openconfig-version?

option (types.gnoi_version) = "1.0.0";

Does the server have to advertise the individual versions per proto? i.e factory reset is 0.1.0, system is 1.0.0, cert is 0.2.0 etc.

[hellt]

Does the server have to advertise the individual versions per proto? i.e factory reset is 0.1.0, system is 1.0.0, cert is 0.2.0 etc.

gNOI services don't have a Capabilities analog. So the server doesn't announce anything.

Currently, what I see is that vendors might document which particular version of a given gnoi service (os, system, cert, etc) they support in which release.
Then the gnoi clients need to use the least common denominator to comply with the implemented service version