Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions rpc/gnmi/gnmi-extensions.md
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Content LGTM.

Also update the revision date and version?

Should we also update to the gnmi spec and gnmi_ext.proto?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated revision date + version.

What do you propose we update in the gNMI spec + proto? Part of the reasons for the modularity of specs we have is to prevent there being a single doc that is somewhat unmaintainable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dplore friendly ping.

Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,9 @@
**Contributors**: Rob Shakir (robjs@google.com), Carl Lebsack (csl@google.com),
Nick Ethier (nethier@jive.com), Anees Shaikh (aashaikh@google.com)

**Updated**: January 25th, 2018
**Updated**: April 7, 2025

**Version**: 0.1.0
**Version**: 0.2.0

## Extending gNMI

Expand Down Expand Up @@ -70,3 +70,14 @@ The `Extension` message consists of a single `oneof` which may contain:
registered extension.
* A `bytes` field which stores the binary-marshalled protobuf for the
extension.

## Error handling

New extensions may be added by a client that are unknown to a server, and
vice versa. For this reason, unknown extensions being present in a message
capable of carrying extensions MUST NOT be treated as an error.

In the case that a known extension is received within an RPC the receiving
entity (client or server) and that extension contains invalid contents
(based on syntax of semantics) then the receiver MAY treat this as an error,
and MAY choose to terminate the corresponding RPC.