Clarification on valid path elements

[srebhan]

With Telegraf we came across a device that uses spaces in path elements (see the corresponding issue), now the question arises if this (show version) is a valid path element.

When reading the GNMI specification there is no clear statement on how a path element is defined. In section 3.1 it states

gNMI is often used to carry payloads that contain data instances of YANG schemas [...]

and this somehow suggests that path elements should correspond to YANG model identifiers. Those identifiers are defined in RFC 6020 section 6.2 as

Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots.

i.e. there is no space allowed.

So the question is, MUST the path elements follow the YANG model identifiers specification or not? If not, what are allowed characters for path elements?

[robshakir]

gNMI does not place a restriction here -- we just require that the path element is defined in terms of a uniquely identifying value that consists of the tuple of the name and keys. Whilst YANG is used to write the schema for some of these trees, other formats (e.g., protobuf) are also used, each has its own rules as to identifiers such that it's not appropriate for gNMI to restrict here (e.g., YANG allows for - but other languages will not).

In the linked issue, I notice that a path is being used in origin: cli -- this is not conformant with the gNMI spec. Section 2.7.1 says:

Where the origin field is set to a command line interface format, the path should be ignored and the value specified within the Update considered as CLI input.

i.e., this use of origin: "cli" path: "show version" is not something that origin: "cli" is intended to support.

r.

[hellt]

Yes, using cli origin with gNMI for running show commands is an uncharted territory. It is not defined in the spec (but may work with more than a couple of vendors already).

You can have a look at https://github.com/openconfig/gnmic where we made sure we are not limited by the underlying gnxi library when doing path parsing. In other words, your request would work.

[srebhan]

Thanks for the clarification everyone! Much appreciated! Just to be sure I got you right, you are saying that cli is not specified as a valid origin?

@hellt we are currently using the gnxi library and if possible we would like to stick with it... I will contact them and point them to this issue though. ;-)