The Extension message is defined within the gnmi_ext.proto
specification. It is carried as a repeated field within each
of the top-level request and response gNMI messages.
The Extension message consists of a single oneof which may contain:
- A well-known extension. Each well known extension defined
in the gnmi_ext.proto file will be added to the oneof and
assigned a unique field tag.
- A registered extension, expressed as a RegisteredExtension message.
The subfields of this message are:
- An enumerated id field used to store the unique ID assigned
to the registered extension.
- A bytes field which stores the binary-marshalled protobuf
for the extension.
extension-field
extension
The Extension message is defined within the gnmi_ext.proto
specification. It is carried as a repeated field within each
of the top-level request and response gNMI messages.
The Extension message consists of a single oneof which may contain:
- A well-known extension. Each well known extension defined
in the gnmi_ext.proto file will be added to the oneof and
assigned a unique field tag.
- A registered extension, expressed as a RegisteredExtension message.
The subfields of this message are:
- An enumerated id field used to store the unique ID assigned
to the registered extension.
- A bytes field which stores the binary-marshalled protobuf
for the extension.
model-data
supported-modules
The ModelData message describes a specific model that is supported
by the target and used by the client. The fields of the ModelData
message identify a data model registered in a model catalog,
as described in [draft-openconfig-netmod-model-catalog]
(the schema of the catalog itself - expressed in YANG - is described
in [openconfig-module-catalog.yang]).
Each model specified by a ModelData message may refer to a specific
schema module, a bundle of modules, or an augmentation or deviation,
as described by the catalog entry.
Each ModelData message contains the following fields:
- name - name of the model expressed as a string.
- organization - the organization publishing the model, expressed
as a string.
- version - the supported (or requested) version of the model,
expressed as a string which represents the semantic version of
the catalog entry.
The combination of name, organization, and version uniquely identifies
an entry in the model catalog.
model-data
supported-modules
The ModelData message describes a specific model that is supported
by the target and used by the client. The fields of the ModelData
message identify a data model registered in a model catalog,
as described in [draft-openconfig-netmod-model-catalog]
(the schema of the catalog itself - expressed in YANG - is described
in [openconfig-module-catalog.yang]).
Each model specified by a ModelData message may refer to a specific
schema module, a bundle of modules, or an augmentation or deviation,
as described by the catalog entry.
Each ModelData message contains the following fields:
- name - name of the model expressed as a string.
- organization - the organization publishing the model, expressed
as a string.
- version - the supported (or requested) version of the model,
expressed as a string which represents the semantic version of
the catalog entry.
The combination of name, organization, and version uniquely identifies
an entry in the model catalog.
notifications
notification
When a target wishes to communicate data relating to the state of
its internal database to an interested client, it does so via means
of a common Notification message. Notification messages are reused
in other higher-layer messages for various purposes.
The creator of a Notification message MUST include the timestamp
field. All other fields are optional.
notifications
notification
When a target wishes to communicate data relating to the state of
its internal database to an interested client, it does so via means
of a common Notification message. Notification messages are reused
in other higher-layer messages for various purposes.
The creator of a Notification message MUST include the timestamp
field. All other fields are optional.
update-list
update
A re-usable Update message is utilised to indicate changes to
paths where a new value is required. The Update message contains
two fields
update-list
update
A re-usable Update message is utilised to indicate changes to
paths where a new value is required. The Update message contains
two fields