Ambiguity between SubscribeResponse and GetResponse proto structure

[ashu-ciena]

Hi, I am not sure why a GET response is not OneOf "repeated notifcations" and "Error"?

Observation 1: if the intention is to return an error to a GET request, the GetResponse structure will have no notifications. However, subscribe response is clear on either send a list of notifications OR an error.

_message GetResponse {
repeated Notification notification = 1; // Data values.
Error error = 2 [deprecated = true]; // Errors that occurred in the Get.
// Extension messages associated with the GetResponse. See the
// gNMI extension specification for further definition.
repeated gnmi_ext.Extension extension = 3;
}

message SubscribeResponse {
oneof response {
Notification update = 1; // Changed or sampled value for a path.
// Indicate target has sent all values associated with the subscription
// at least once.
bool sync_response = 3;
// Deprecated in favour of google.golang.org/genproto/googleapis/rpc/status
Error error = 4 [deprecated = true];
}
// Extension messages associated with the SubscribeResponse. See the
// gNMI extension specification for further definition.
repeated gnmi_ext.Extension extension = 5;
}_

Observation 2: The deprecation comment to use grpc::Status is also missing in the GetResponse message.

Can someone explain why GetResponse message is designed so?

Thanks,

[earies]

IMO - all focus has been on Subscribe which has widened these gaps over time.

Get is also likely where we see the most divergence in the industry with partial support and overall scale concerns due to the design/intent - More often than not, a Subscribe as ONCE suffices for similar purposes and a Get is centric around configuration retrieval as a single document much like NETCONF get-config, classical screen scraping/config backup, etc...

I would like to hear from others on this topic if there is desire to discuss and enhance the Get API or scope it appropriately and leave as-is.

[ashu-ciena]

@dplore, I added this topic as a proposed item in the open config community meeting notes for the 2nd of July meeting. Can you review this observation?

[ashu-ciena]

@navaneethyv I realized there won't be any open config meeting till Aug 9. Can we invite comments from community over here? Can someone from gnmi spec draft team respond to my query?