Encoding of leaf values

[pmartinou]

There seems to be a discrepancy between the specification text in "2.2.3 Node Values" and the examples in "2.3.1" of the gNMI specification:

In the example tree, we have: /a/b[name=1]/c/e (uint32)

If we follow the text in 2.2.3, the server should return a TypedValue with uint_val: 123

But the example text in 2.3.1 shows: json_val: 10042 // decoded byte array

[robshakir]

Thanks. I think we need some clarifications here. We expect that the leaf-encoding is based on how the subscription is requested. In the case that the client wants JSON-encoded values, then the json_val would need to be used. We should clarify that the native type encodings should be using protobuf as the encoding option.

@gcsl -- do you think the above is consistent?

[gcsl]

It appears to me that we missed updating the wording in the spec in 2.3 with respect to the TypedValue message as the enum descriptions there seem to be with reference to the old value encoding. With TypedValue we deprecated the need for the enumeration in the Updates and should have updated the spec to reflect the enumeration meaning with respect to the <Get|Set|Subscribe>Request messages.

On Thu, Nov 16, 2017 at 7:42 PM, Rob Shakir notifications@github.com wrote:

Thanks. I think we need some clarifications here. We expect that the leaf-encoding is based on how the subscription is requested. In the case that the client wants JSON-encoded values, then the json_val would need to be used. We should clarify that the native type encodings should be using protobuf as the encoding option.

@gcsl https://github.com/gcsl -- do you think the above is consistent?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openconfig/reference/issues/75#issuecomment-345137156, or mute the thread https://github.com/notifications/unsubscribe-auth/ARfIL-Mb8nNzdgz3R0kXLU0_md0WLSF_ks5s3QCxgaJpZM4Poc_K .

[mberroug]

Hello,

When requested encoding format is JSON or JSON_IETF, in 2.3.1 JSON and JSON_IETF examples, json_val or json_ietf_val of the TypedValue message will be used.

For requested leaf node, we will have a problem when we json-decode json_val or json_ietf_val as what we return in this case don't respect JSON format ( RFC7159 or RFC7951). In the exmaple referenced by @pmartinou , we should have json_val : { "e": 10042 } and not json_val: 10042

I prefer the we use in this case the corresponding TypedValue of the requested leaf (string_val, int64 ,int_val ...)

[robshakir]

If a particular leaf is requested, then sending a scalar (not a JSON object is fine). A json_val of 10042 is completely valid:

>>> import json
>>> json.loads("10042")
10042

So in a Get request that specifies the JSON or JSON_IETF encoding, then I would expect that raw value is used. Only if the PROTO encoding is specified there would one use the TypedValue field for leaf values.

[idefixcert]

Just to clarify: on subscribe if I have:

 root +
      |
      +-- a +
            |
            +-- b[name=b1] +
                           |
                           +-- c +
                                 |
                                 +-- d (string)
                                 +-- e (uint32)

and I subscribe a/b[name=b1]/c would I get now a JSON Encoding of c, or would I get to different update notifications for dand e?

And if it is the json representation of c, is it allowed to subscribe also for dand e?

I am not sure if I can say (in yang) the leaf is: /interfaces/interface/config of if each attribute in config has to be leaf. (e.g. /interfaces/interface/config/AdminStatus ...)

[ashu-ciena]

Hello @idefixcert @robshakir @gcsl Was there any conclusion on the last question / message in this thread? I also have the same question. Whether to send out 2 updates for d and e each keeping the parent path in gnmi::Path structure OR aggregate both d and e together in json_val like {"d": "val1", "e": "val2"} keeping the path till c in gnmi::Path structure.

What if the subscription is on they list element b with a key b1? should we do the aggregation by default or send individual update messages with only 1 leaf key-value pair?