Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

errors in SetResponse (proto vs. spec) #62

Open
allyn-wade opened this issue Jul 11, 2017 · 3 comments · May be fixed by #157
Open

errors in SetResponse (proto vs. spec) #62

allyn-wade opened this issue Jul 11, 2017 · 3 comments · May be fixed by #157

Comments

@allyn-wade
Copy link

Looking at the latest gnmi.proto, I see that Error has been deprecated, as has all its uses, including within SetResponse and UpdateResult.

However Section 3.4 still says that "In the case of a failure of an operation, the status of the UpdateResult message MUST be populated with error information as per the specification in Section 3.4.7.".

Similarly, 3.4.7 still says that we "MUST set the message field of the UpdateResult corresponding to the failed operation to an Error message indicating failure. In the case that the processed operation is not the only operation within the SetRequest the target MUST set the message field of the UpdateResult messages for all other operations, setting the code field to Aborted (10).".

I woulds image the proto is correct and the spec just hasn't been updated to agree yet - can this be clarified?

@robshakir
Copy link
Contributor

This is indeed a spec error, thanks for pointing it out. We'll update the spec.

@AtosNicoS
Copy link

Is this spec still under development? The issue is over a year old now. I am searching for something to configure network and other devices over grpc and it would be best to not reinvent everything. So can we still expect further improvements of this document and a proper RFC?

@robshakir
Copy link
Contributor

robshakir commented Aug 14, 2018

The specification is under active development. We did update the specification to cover some of these cases, and are continuing to work through clarifications that are needed based on completing implementations with a number of vendors.

Our approach to development has been iterative, as this allows us to find real implementation issues and specification clarifications. The gNMI service is implemented on a number of major vendor's implementations (e.g., Arista, Juniper, Cisco, Ciena, Nokia, as well as a number of other in-progress or private implementations). As with all specifications during their implementation, there will be improvements as we find implementation challenges, or ambiguities across different implementations. There are now reference implementations for telemetry (in the openconfig/gnmi and the google/gnxi repositories).

We have taken the approach that the document in this repo is the authoritative source of the specification for gNMI and its extension documents. The contributors have been across multiple companies. The IETF has other solutions (NETCONF, RESTCONF) - and has been somewhat hesistant to rely on third-party underlying technologies (although this issue has not been re-examined since gRPC became a CNCF project). At this time we do not have any intention to take this document into a full RFC, since it seems to constrain the community's ability to iterate on it. An RFC is not the sole mechanism of communicating a standard.

If you have specific other questions -- please do let us know, and we can try and clarify. It is likely to be better to open individual issues.

Thanks,
r.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants